Systems and methods for identifying financial relationships

ABSTRACT

Improved systems and methods are provided for identifying financial relationships. In particular, financial relationships may be identified by associating tradelines with one or more people who sign or co-sign on the tradeline. In various embodiments a method is provided comprising, receiving, at a computer-based system for credit data analysis comprising a processor and a tangible, non-transitory memory, credit reporting data relating to a tradeline, parsing, by the computer-based system, the credit reporting data to yield primary debtor data and secondary debtor data, and linking, by the computer-based system, the tradeline with the primary debtor data and the secondary debtor data.

FIELD

This disclosure generally relates to financial data processing, and inparticular it relates to identifying and analyzing financialrelationships.

BACKGROUND

Financial relationships amongst people arise for a variety of reasons.Married couples tend to have a financial relationship which may includejoint and several liability with respect to debt obligations (e.g.,mortgage loans, automobile loans, and transaction accounts). Parents mayco-sign or guarantee debt obligations of their children, especially whenthe children are young adults. Siblings may also have mutual debtobligations, such as a mortgage loan on an investment property.Financial relationships tend to be strongest when the borrowers residein the same physical location, though strong financial relationshipsexist amongst people who do not reside in the same physical location. Inthese situations, and others, credit issuers may desire a more detailedanalysis of a consumer's financial relationships. However, creditbureaus are not able to accomplish this as the co-signer(s) of atradeline is/are not necessarily retained in credit bureau records.Thus, there is a need for systems and methods to identify and analyzefinancial relationships, such as those financial relationships thatinclude a shared tradeline.

SUMMARY

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, andlinking, by the computer-based system, the tradeline with the primarydebtor data and the secondary debtor data. In various embodiments themethod further comprises determining whether the primary debtor and thesecondary debtor reside at the same physical address

In various embodiments a method is provided comprising a non-transitorymemory communicating with a processor, the non-transitory memory havinginstructions stored thereon that, in response to execution by theprocessor, cause the processor to perform operations comprisingreceiving, by the processor, credit reporting data relating to atradeline, and parsing, by the processor, the credit reporting data toyield primary debtor data and secondary debtor data and linking, by theprocessor, the tradeline with the primary debtor data and the secondarydebtor data. In various embodiments the method further compriseslinking, by the computer-based system, the tradeline data with theprimary debtor and the secondary debtor in the data store

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint, querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint. In various embodiments the method further comprises whereina credit score is derived from the household tradeline data set and themaking a credit approval decision is further made based upon the creditscore

In various embodiments a method is provided comprising a non-transitorymemory communicating with a processor, the non-transitory memory havinginstructions stored thereon that, in response to execution by theprocessor, cause the processor to perform operations comprisingidentifying, by the processor, tradeline data associated with a primarydebtor in a data store containing credit bureau data, combining, by theprocessor, a subset of the tradeline data using a fingerprintingfunction to yield a tradeline fingerprint, querying, by the processor,the data store for the tradeline fingerprint to retrieve a secondarydebtor associated with the tradeline fingerprint.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data identifies a primary debtor and wherein thesecondary debtor data identifies a secondary debtor, linking, by thecomputer-based system, the tradeline with the primary debtor data andthe secondary debtor data, wherein the linking causes the tradeline tobe associated with the primary debtor and the secondary debtor,querying, by the computer-based system, the data store for tradelinesassociated with the primary debtor and the secondary debtor, wherein thequerying yields a household tradeline data set, marketing at least oneof a product and service based upon at least one of the householdtradeline data set, the primary debtor data and the secondary debtordata.

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradeline fingerprintquerying, by the computer-based system, the data store for primarydebtor data relating to the primary debtor and secondary debtor datarelating to the secondary debtor querying the data store for tradelinesassociated the primary debtor and the secondary debtor, wherein thequerying yields a household tradeline data set, and marketing at leastone of a product and service based upon at least one of the householdtradeline data set, the primary debtor data and the secondary debtordata.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline parsing', by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data identifies a primary debtor and wherein thesecondary debtor data identifies a secondary debtor, linking, by thecomputer-based system, the tradeline with the primary debtor data andthe secondary debtor data, wherein the linking causes the tradeline tobe associated with the primary debtor and the secondary debtor,querying, by the computer-based system, the data store for tradelinesassociated with the primary debtor and the secondary debtor, wherein thequerying yields a household tradeline data set, making a credit approvaldecision based upon the household tradeline data set.

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint, querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint, querying, by the computer-based system, the data store forprimary debtor data relating to the primary debtor and secondary debtordata relating to the secondary debtor, querying the data store fortradelines associated the primary debtor and the secondary debtor,wherein the querying yields a household tradeline data set, and making acredit approval decision based upon the household tradeline data set.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data identifies a primary debtor and wherein thesecondary debtor data identifies a secondary debtor, and wherein adebtor entity comprises the primary debtor and the secondary debtor,linking, by the computer-based system, the tradeline with the primarydebtor data and the secondary debtor data, wherein the linking causesthe tradeline to be associated with the primary debtor and the secondarydebtor, querying, by the computer-based system, the data store fortradelines associated with the primary debtor and the secondary debtor,wherein the querying yields a household tradeline data set, identifying,by the computer-based system, any balance transfers within the householdtradeline data set, discounting, by the computer-based system, theamount of the balance transfers from any spending identified in thehousehold tradeline data set, and determining, by the computer-basedsystem, a purchasing ability of the debtor entity based on the householdtradeline data set, the discounting, and a model of consumer spendingpatterns

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint, querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint, querying, by the computer-based system, the data store forprimary debtor data relating to the primary debtor and secondary debtordata relating to the secondary debtor, querying the data store fortradelines associated the primary debtor and the secondary debtor,wherein the querying yields a household tradeline data set, andidentifying, by the computer-based system, any balance transfers withinthe household tradeline data set, discounting, by the computer-basedsystem, the amount of the balance transfers from any spending identifiedin the household tradeline data set, and determining, by thecomputer-based system, a purchasing ability of the debtor entity basedon the household tradeline data set, the discounting, and a model ofconsumer spending patterns derived from individual and aggregateconsumer data.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data identifies a primary debtor and wherein thesecondary debtor data identifies a secondary debtor, and wherein adebtor entity comprises the primary debtor and the secondary debtor,linking, by the computer-based system, the tradeline with the primarydebtor data and the secondary debtor data, wherein the linking causesthe tradeline to be associated with the primary debtor and the secondarydebtor, querying, by the computer-based system, the data store fortradelines associated with the primary debtor and the secondary debtor,wherein the querying yields a household tradeline data set, estimating,by the computer-based system, credit-related information of the debtorentity based on the household tradeline data set, a previous balancetransfer, and a model of consumer spending patterns, wherein thecredit-related information comprises a spend amount associated with thedebtor entity, and offsetting, by the computer-based system, theprevious balance transfers from the estimated credit-relatedinformation.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, wherein the credit reporting data is encapsulated in aMetro 2 format container, parsing, by the computer-based system, thecredit reporting data to yield primary debtor data and secondary debtordata, linking, by the computer-based system, the tradeline with theprimary debtor data and the secondary debtor data.

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, whereinthe tradeline data is associated with a tradeline, combining, by thecomputer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint, querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint.

In various embodiments a method is provided comprising a non-transitorymemory communicating with a processor, the non-transitory memory havinginstructions stored thereon that, in response to execution by theprocessor, cause the processor to perform operations comprisingreceiving, at the processor, credit reporting data relating to atradeline, wherein the credit reporting data is encapsulated in a Metro2 format container, parsing, by the processor, the credit reporting datato yield primary debtor data and secondary debtor data, linking, by theprocessor, the tradeline with the primary debtor data and the secondarydebtor data.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, linking, bythe computer-based system, the tradeline with the primary debtor dataand the secondary debtor data, and querying, by the computer-basedsystem, a data store containing credit bureau data for a physicaladdress associated with the primary debtor and a physical addressassociated with the secondary debtor, and determining, by thecomputer-based system, that the primary debtor and the secondary debtorreside at the different physical addresses.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data identifies a primary debtor and wherein thesecondary debtor data identifies a secondary debtor, and wherein adebtor entity comprises the primary debtor and the secondary debtor,linking, by the computer-based system, the tradeline with the primarydebtor data and the secondary debtor data, wherein the linking causesthe tradeline to be associated with the primary debtor and the secondarydebtor, querying, by the computer-based system, a data store containingcredit bureau data for a physical address associated with the primarydebtor and a physical address associated with the secondary debtor, anddetermining, by the computer-based system, that the primary debtor andthe secondary debtor reside at the different physical addresses.

In various embodiments a method is provided comprising, receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data is associated with a primary debtor and thesecondary debtor data is associated with a secondary debtor and whereina debtor entity comprises the primary debtor and the secondary debtor,and linking, by the computer-based system, the tradeline with theprimary debtor data and the secondary debtor data, querying, by thecomputer-based system, a data store comprising credit bureau data toretrieve debtor entity tradeline data comprising tradeline dataassociated with at least one of the primary debtor and the secondarydebtor.

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint, querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint, wherein a debtor entity comprises the primary debtor andthe secondary debtor, querying, by the computer-based system, the datastore to retrieve debtor entity tradeline data comprising tradeline dataassociated with at least one of the primary debtor and the secondarydebtor.

In various embodiments, a system is provided for credit data analysiscomprising, a non-transitory memory communicating with a processor, thenon-transitory memory having instructions stored thereon that, inresponse to execution by the processor, cause the processor to performoperations comprising, receiving, by the processor, credit reportingdata relating to a tradeline, parsing, by the processor, the creditreporting data to yield primary debtor data and secondary debtor data,wherein the primary debtor data is associated with a primary debtor andthe secondary debtor data is associated with a secondary debtor andwherein a debtor entity comprises the primary debtor and the secondarydebtor, and linking, by the processor, the tradeline with the primarydebtor data and the secondary debtor data, querying, by the processor, adata store comprising credit bureau data to retrieve debtor entitytradeline data comprising tradeline data associated with at least one ofthe primary debtor and the secondary debtor.

In various embodiments a method is provided comprising, receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data is associated with a primary debtor and thesecondary debtor data is associated with a secondary debtor and whereina debtor entity comprises the primary debtor and the secondary debtor,and linking, by the computer-based system, the tradeline with theprimary debtor data and the secondary debtor data, querying, by thecomputer-based system, an internal data store to retrieve debtor entityinternal data comprising internal data associated with at least onetransaction account of at least one of the primary debtor and thesecondary debtor.

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint, wherein a debtor entity comprises the primary debtor andthe secondary debtor, querying, by the computer-based system, aninternal data store to retrieve debtor entity internal data comprisinginternal data associated with at least one transaction account of atleast one of the primary debtor and the secondary debtor.

In various embodiments a method is provided comprising receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, parsing, by the computer-based system, the credit reportingdata to yield primary debtor data and secondary debtor data, wherein theprimary debtor data is associated with a primary debtor and thesecondary debtor data is associated with a secondary debtor and whereina debtor entity comprises the primary debtor and the secondary debtor,and linking, by the computer-based system, the tradeline with theprimary debtor data and the secondary debtor data, querying, by thecomputer-based system, a data store comprising credit bureau data toretrieve debtor entity tradeline data including an installmenttradeline, wherein the installment tradeline is associated with theprimary debtor and the secondary debtor.

In various embodiments a method is provided comprising identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, combining,by the computer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint, querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint, wherein a debtor entity comprises the primary debtor andthe secondary debtor, querying, by the computer-based system, the datastore comprising credit bureau data to retrieve debtor entity tradelinedata including an installment tradeline, wherein the installmenttradeline is associated with the primary debtor and the secondarydebtor.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the present disclosure and, togetherwith the description, further serve to explain the principles of thedisclosure and to enable a person skilled in the pertinent art to makeand use the disclosed embodiments.

FIGS. 1A and 1B are block diagrams of an exemplary financial dataexchange network over which the processes of the present disclosure maybe performed;

FIG. 2 is a flowchart of an exemplary consumer modeling processperformed by the financial server of FIG. 1;

FIG. 3 is a diagram of exemplary categories of consumers examined duringthe process of FIG. 2;

FIG. 4 is a diagram of exemplary subcategories of consumers modeledduring the process of FIG. 2;

FIG. 5 is a diagram of financial data used for model generation andvalidation according to the process of FIG. 2;

FIG. 6 is a flowchart of an exemplary process for estimating the spendability of a consumer, performed by the financial server of FIG. 1;

FIG. 7-10 are exemplary timelines showing the rolling time periods forwhich individual customer data is examined during the process of FIG. 6;

FIG. 11-19 are tables showing exemplary results and outputs of theprocess of FIG. 6 against a sample consumer population;

FIG. 20 is a flowchart of an exemplary method for determining ahousehold size of wallet;

FIG. 21 is a chart identifying various example household types;

FIG. 22 is a chart illustrating average sizes of wallet by householdtype;

FIG. 23 is a chart illustrating spend opportunity based on an exemplaryshare of wallet distribution;

FIG. 24 illustrates a method of linking in accordance with variousembodiments;

FIG. 25 illustrates a Venn diagram of debtor tradelines in accordancewith various embodiments;

FIG. 26 illustrates an additional method of linking in accordance withvarious embodiments;

FIG. 27 illustrates a method of marketing in accordance with variousembodiments;

FIG. 28 illustrates a method of parsing in accordance with variousembodiments; and

FIG. 29 illustrates a method of using internal data in accordance withvarious embodiments.

DETAILED DESCRIPTION

The detailed description of exemplary embodiments herein makes referenceto the accompanying drawings and pictures, which show the exemplaryembodiment by way of illustration and its best mode. While theseexemplary embodiments are described in sufficient detail to enable thoseskilled in the art to practice the disclosure, it should be understoodthat other embodiments may be realized and that logical and mechanicalchanges may be made without departing from the spirit and scope of thedisclosure. Thus, the detailed description herein is presented forpurposes of illustration only and not of limitation. For example, thesteps recited in any of the method or process descriptions may beexecuted in any order and are not limited to the order presented.Moreover, any of the functions or steps may be outsourced to orperformed by one or more third parties. Furthermore, any reference tosingular includes plural embodiments, and any reference to more than onecomponent may include a singular embodiment.

Systems, methods and computer program products are provided. In thedetailed description herein, references to “various embodiments”, “oneembodiment”, “an embodiment”, “an example embodiment”, etc., indicatethat the embodiment described may include a particular feature,structure, or characteristic, but every embodiment may not necessarilyinclude the particular feature, structure, or characteristic. Moreover,such phrases are not necessarily referring to the same embodiment.Further, when a particular feature, structure, or characteristic isdescribed in connection with an embodiment, it is submitted that it iswithin the knowledge of one skilled in the art to effect such feature,structure, or characteristic in connection with other embodimentswhether or not explicitly described. After reading the description, itwill be apparent to one skilled in the relevant art(s) how to implementthe disclosure in alternative embodiments.

Internal data includes any data a credit issuer possesses or acquirespertaining to a particular consumer. Internal data may be gatheredbefore, during, or after a relationship between the credit issuer andthe consumer. Such data may include consumer demographic data. Consumerdemographic data includes any data pertaining to a consumer. Consumerdemographic data may include consumer name, address, telephone number,email address, employer and social security number. Consumertransactional data is any data pertaining to the particular transactionsin which a consumer engages during any given time period. Consumertransactional data may include transaction amount, transaction time,transaction vendor/merchant, and transaction vendor/merchant location.Transaction vendor/merchant location may contain a high degree ofspecificity to a vendor/merchant. For example, transactionvendor/merchant location may include a particular gasoline filingstation in a particular postal code located at a particular crosssection or address. Also for example, transaction vendor/merchantlocation may include a particular web address, such as a UniformResource Locator (“URL”), an email address and/or an Internet Protocol(“IP”) address for a vendor/merchant. Transaction vendor/merchantlocation may also include information gathered from a WHOIS databasepertaining to the registration of a particular web or IP address. WHOISdatabases include databases that contain data pertaining to Internet IPaddress registrations. Transaction vendor/merchant, and transactionvendor/merchant location may be associated with a particular consumerand further associated with sets of consumers. Consumer payment dataincludes any data pertaining to a consumer's history of paying debtobligations. Consumer payment data may include consumer payment dates,payment amounts, balance amount, and credit limit. Internal data mayfurther comprise records of consumer service calls, complaints, requestsfor credit line increases, questions, and comments. A record of aconsumer service call includes, for example, date of call, reason forcall, and any transcript or summary of the actual call.

Internal data may further comprise closed-loop data and open-loop data.Closed-loop data includes data obtained from a credit issuer'sclosed-loop transaction system. A closed-loop transaction systemincludes transaction systems under the control of one party. Closed-looptransaction systems may be used to obtain consumer transactional data.Open-loop data includes data obtained from a credit issuer's open-looptransaction system. An open-loop transaction system includes transactionsystems under the control of multiple parties.

Credit bureau data includes any data received and/or retained by acredit bureau pertaining to a particular consumer. A credit bureauincludes any organization that collects and/or distributes consumerdata. A credit bureau may be a consumer reporting agency. Credit bureausgenerally collect financial information pertaining to consumers. Creditbureau data may include, for example, consumer account data, creditlimits, balances, and payment history. Credit bureau data may includecredit bureau scores that reflect a consumer's creditworthiness. Creditbureau scores are developed from data available in a consumer's filesuch as, for example, the amount of lines of credit, paymentperformance, balance, and number of tradelines. Consumer data is used tomodel the risk of a consumer over a period of time using statisticalregression analysis. In one embodiment, those data elements that arefound to be indicative of risk are weighted and combined to determinethe credit score. For example, each data element may be given a score,with the final credit score being the sum of the data element scores.

As used herein, a debtor may mean a consumer or business that eitherowes or may owe money to another party, such as a credit issuer. Thus, adebtor includes consumers who have not yet borrow money but may apply orhave applied to receive a loan.

Credit bureaus may receive credit bureau reporting data from a reportingentity (e.g., a credit issuer) using a standardized format, such as anXML scheme or other structured data container. For example, the METRO 2container is standardized format. The METRO 2 container may one or moreof a Header Record, a Base Segment, a J1 Segment, a J2 Segment, a K1Segment, and a Trailer Record. The METRO 2 container may be a fixedwidth file meaning, for example, each data field may be designated afixed width that it may not exceed. The METRO 2 container may comprise adelimited file where each data field is delimited by a delimiter, such acomma, semicolon, or pipe “|” character. The METRO 2 container may beformatted in accordance with an XML schema. Credit bureau reporting datamay be reported periodically by a credit issuer to report on the statusof a particular tradeline.

The METRO 2 Header Record may be formatted as:

Header Record Field Field Name Length Position Source 1 Record 4 1-4Line Length Descriptor 2 Record Identifier 6  5-10 Header 3 Cycle Number2 11-12 Cycle Reporting -- BLANK 4 CCA Identifier 10 13-22 BLANK 5Equifax 10 23-32 Credit Bureau Setup Equifax Identifier Credit Grantor #6 Experian 5 33-37 Credit Bureau Setup Identifier Experian Control # 7Trans Union 10 38-47 Credit Bureau Setup TU Identifier Credit Grantor #8 Activity Date 8 48-55 Last update to account balances 9 Date Created 856-63 Credit Report Date 10 Program Date 8 64-71 Internal Program Date11 Program 8 73-79 Internal Program Date Revision Date 12 Reporter Name40  80-119 Company Details Name 13 Reported 96 120-215 Company DetailsAddress Address Lines 1-3 14 Reporter Phone 10 216-225 Company DetailsPhone 15 Reserved 201 226-426 Program Creator and Version -- Help About

The METRO 2 Base Segment may be formatted as:

Base Segment Field Field Name Length Position Source 1 Record Descriptor4 1-4 Record length 2 Processing Indicator 1  5 Processing instruction 3Time Stamp 14  6-19 Contact created Date and Time 4 Correction Indicator1  20 Internal 5 Identification 20 21-40 Credit Bureau Setup NumberIdentification # 6 Cycle Identifier 2 41-42 Cycle Reporting -- BLANK 7Consumer Account 30 43-72 Debtor File # or Client Number Account # 8Portfolio Type 1  73 Credit Report Details Portfolio 9 Account Type 274-75 Credit Report Details Account Type 10 Date Opened 8 76-83 DebtorListed Date 11 Credit Limit 9 84-92 ZERO FILL 12 Highest Credit or 9 93-101 Debtor Principal Original Loan Amount 13 Terms Duration 3102-104 001 14 Terms Frequency 1 105 BLANK 15 Scheduled Monthly 9106-114 ZERO FILL Payment Amount 16 Actual Payment 9 115-123 PaymentTransactions Amount Amount 17A Account Status 2 124-125 Credit ReportDetails Status Code 17B Payment Rating 1 126 BLANK 18 Payment History 24127-150 B - No Payment History Profile 19 Special Comment 2 151-152Credit Report Details Special Comments 20 Compliance 2 153-154 CreditReport Details Condition Code Condition Code 21 Current Balance 9155-163 Debtor Owing 22 Amount Past Due 9 164-172 ZERO FILL 23 OriginalCharge-off 9 173-181 ZERO FILL Amount 24 Date of Account 8 182-189Credit Report Date Information 25 FCRA Compliance/ 8 190-197 DebtorDelnqnt or zero Date of First filled if Current Delinquency 26 DateClosed 8 198-205 Metro Contact Date or zero filled if not Closed 27 Dateof Last Payment 8 206-213 Debtor Payment 28 Reserved 17 214-230 BLANK 29Consumer 1 231 Internal Transaction Type 30 Surname 25 232-256 DebtorName 31 First Name 20 257-276 Debtor Name 32 Middle Name 20 277-296BLANK 33 Generation Code 1 297 Debtor Generation 34 Social Security 9298-306 Debtor SSN# Number 35 Date of Birth 8 307-314 Debtor DOB 36Telephone Number 10 315-324 Debtor Home 37 ECOA Code 1 325 Credit ReportDetails Association Code (ECOA) 38 Consumer 2 326-327 Credit ReportDetails Information Indicator Indicator 39 Country Code 2 328-329 DebtorCountry 40 First Line of Address 32 330-361 Debtor Address 41 SecondLine of 32 362-393 Debtor Address Line 2 Address 42 City 20 394-413Debtor City 43 State 2 414-415 Debtor State 44 Postal/Zip Code 9 416-424Debtor Zip 45 Address Indicator 1 425 Debtor Address OK 46 ResidenceCode 1 426 BLANK

The METRO 2 J1 Segment may be formatted as:

Field Same Address Field Field Name Length Position Source 1 SegmentIdentifier 2 1-2 J1 2 Consumer 1  3 Internal Transaction Type 3 Surname25  4-28 Debtor Cosigner Name 4 First Name 20 29-48 Debtor Cosigner Name5 Middle Name 20 49-68 BLANK 6 Generation Code 1  69 Debtor CosignerGeneration 7 Social Security 9 70-78 Debtor Cosigner SSN Number 8 Dateof Birth 8 79-86 Debtor Cosigner DOB 9 Telephone Number 10 87-96 DebtorCosigner Home 10 ECOA Code 1  97 Debtor Cosigner ECOA 11 Consumer 298-99 Debtor Cosigner Indicator Information Indicator 12 Reserved 1 100BLANK

The METRO 2 J2 Segment may be formatted as:

J2 Segment Different Address Field Field Name Length Position Source 1Segment Identifier 2 1-2 J2 2 Consumer 1  3 Internal Transaction Type 3Surname 25  4-28 Debtor Cosigner Name 4 First Name 20 29-48 DebtorCosigner Name 5 Middle Name 20 49-68 BLANK 6 Generation Code 1  69Debtor Cosigner Generation 7 Social Security 9 70-78 Debtor Cosigner SSNNumber 8 Date of Birth 8 79-86 Debtor Cosigner DOB 9 Telephone Number 1087-96 Debtor Cosigner Home 10 ECOA Code 1  97 Debtor Cosigner ECOA 11Consumer 2 98-99 Debtor Cosigner Information Indicator Indicator 12Country Code 2 100-101 Debtor Cosigner Country 13 First Line of 32102-133 Debtor Cosigner Address Address Line 1 14 Second Line of 32134-165 Debtor Cosigner Address Address Line 2 15 City 20 166-185 DebtorCosigner City 16 State 2 186-187 Debtor Cosigner State 17 Postal/ZipCode 9 188-196 Debtor Cosigner Zip 18 Address Indicator 1 197 DebtorCosigner Address OK 19 Residence Code 1 198 BLANK 20 Reserved 2 199-200BLANK

The METRO 2 K1 Segment may be formatted as:

K1 Segment Field Field Name Length Position Source 1 Segment Identifier2 1-2 K1 2 Original Creditor Name 30  3-32 Client Name 3 CreditorClassification 2 33-34 Client Type

A debt obligation includes any obligation a consumer has to pay alender. Any extension of credit from a lender to a consumer is alsoconsidered a debt obligation. A debt obligation may be secured orunsecured. Secured obligations may be secured with either real orpersonal property. A loan or a credit account are types of debtobligations, and a security backed by debt obligations is considered adebt obligation itself. A mortgage includes a loan, typically in theform of a promissory note, secured by real property. The real propertymay be secured by any legal means, such as, for example, via a mortgageor deed of trust. For convenience, a mortgage is used herein to refer toa loan secured by real property. An automobile loan includes a loan,typically in the form of a promissory note, which is secured by anautomobile. For convenience, an automobile loan is used herein to referto a loan secured by an automobile.

A trade or tradeline includes a credit or charge vehicle typicallyissued to an individual consumer by a credit issuer. Types of tradelinesinclude, for example, installment accounts such as bank loans, studentloans, home equity loans, automobile loans/leases, and mortgages andrevolving accounts such as credit card accounts (e.g., a transactionaccount), charge card accounts (e.g., a transaction account), retailcards, and personal lines of credit.

Tradeline data includes the consumer's account status and activity suchas, for example, names of companies where the consumer has accounts,dates such accounts were opened, credit limits, types of accounts,balances over a period of time and summary payment histories. Tradelinedata is generally available for the vast majority of actual consumers.Tradeline data, however, typically does not include individualtransaction data, which is largely unavailable because of consumerprivacy protections. Tradeline data may be used to determine bothindividual and aggregated consumer spending patterns, as describedherein. Tradeline data may further include negative credit information,such as late payment histories, write-offs, settlements, judgments, andother indicia that the balance associated with the tradeline was notpaid in accordance with an underlying loan agreement.

Any transaction account or credit account discussed herein may includean account or an account number. An “account” or “account number”, asused herein, may include any device, code, number, letter, symbol,digital certificate, smart chip, digital signal, analog signal,biometric or other identifier/indicia suitably configured to allow theconsumer to access, interact with or communicate with the system (e.g.,one or more of an authorization/access code, personal identificationnumber (PIN), Internet code, other identification code, and/or thelike). The account number may optionally be located on or associatedwith a rewards card, charge card, credit card, debit card, prepaid card,telephone card, embossed card, smart card, magnetic stripe card, barcode card, transponder, radio frequency card or an associated account.The system may include or interface with any of the foregoing cards ordevices, or a fob having a transponder and RFID reader in RFcommunication with the fob. Although the system may include a fobembodiment, the invention is not to be so limited. Indeed, system mayinclude any device having a transponder which is configured tocommunicate with RFID reader via RF communication. Typical devices mayinclude, for example, a key ring, tag, card, cell phone, wristwatch orany such form capable of being presented for interrogation. Moreover,the system, computing unit or device discussed herein may include a“pervasive computing device,” which may include a traditionallynon-computerized device that is embedded with a computing unit. Examplescan include watches, Internet enabled kitchen appliances, restauranttables embedded with RF readers, wallets or purses with imbeddedtransponders, etc.

A lender or credit issuer includes any person, entity, software and/orhardware that provides lending services. A lender may deal in secured orunsecured debt obligations. A lender may engage in secured debtobligations where either real or personal property acts as collateral. Alender need not originate loans but may hold securities backed by debtobligations. A lender may be only a subunit or subdivision of a largerorganization. A mortgage holder includes any person or entity that isentitled to repayment of a mortgage. An automobile loan holder is anyperson or entity that is entitled to repayment of an automobile loan. Asused herein, the terms lender and credit issuer may be usedinterchangeably. Credit issuers may include financial services companiesthat issue credit to consumers.

Furthermore, the terms “business” or “merchant” may be usedinterchangeably with each other and shall mean any person, entity,distributor system, software and/or hardware that is a provider, brokerand/or any other entity in the distribution chain of goods or services.For example, a merchant may be a grocery store, a retail store, a travelagency, a service provider, an on-line merchant or the like.

Systems and methods disclosed herein may be useful in conjunction with adetermination of a size of wallet and/or share of wallet. Systems andmethods related to size of wallet and/or share of wallet are describedin U.S. Pat. No. 7,788,147, filed Oct. 29, 2004 and entitled, “Methodand apparatus for estimating the spend capacity of consumers,” and U.S.Pat. No. 7,912,770, filed Jun. 20, 2005 and entitled, “Method andapparatus for consumer interaction based on spend capacity,” and U.S.patent application Ser. No. 11/497,563, filed Aug. 2, 2006 and entitled,“Determining commercial share of wallet,” all of which are incorporatedherein by reference.

Size of Wallet

Technology advances have made it possible to store, manipulate and modellarge amounts of time series data with minimal expenditure on equipment.As will now be described, a financial institution may leverage thesetechnological advances in conjunction with the types of consumer datapresently available in the marketplace to more readily estimate thespend capacity of potential and actual customers. A reliable capabilityto assess the size of a consumer's wallet is introduced in whichaggregate time series and raw tradeline data are used to model consumerbehavior and attributes, and identify categories of consumers based onaggregate behavior. The use of raw trade-line time series data, andmodeled consumer behavior attributes, including but not limited to,consumer panel data and internal consumer data, allows actual consumerspend behavior to be derived from point in time balance information.

In addition, the advent of consumer panel data provided through internechannels provides continuous access to actual consumer spend informationfor model validation and refinement. Industry data, including consumerpanel information having consumer statement and individual transactiondata, may be used as inputs to the model and for subsequent verificationand validation of its accuracy. The model is developed and refined usingactual consumer information with the goals of improving the customerexperience and increasing billings growth by identifying and leveragingincreased consumer spend opportunities.

A credit provider or other financial institution may also make use ofinternal proprietary customer data retrieved from its stored internalfinancial records. Such internal data provides access to even moreactual customer spending information, and may be used in thedevelopment, refinement and validation of aggregated consumer spendingmodels, as well as verification of the models' applicability to existingindividual customers on an ongoing basis.

While there has long been market place interest in understanding spendto align offers with consumers and assign credit line size, the holisticapproach of using a size of wallet calculation across customers'lifecycles (that is, acquisitions through collections) has notpreviously been provided. The various data sources outlined aboveprovide the opportunity for unique model logic development anddeployment, and as described in more detail in the following, variouscategories of consumers may be readily identified from aggregate andindividual data. In certain embodiments of the processes disclosedherein, the models may be used to identify specific types of consumers,nominally labeled ‘transactors’ and ‘revolvers,’ based on aggregatespending behavior, and to then identify individual customers andprospects that fall into one of these categories. Consumers falling intothese categories may then be offered commensurate purchasing incentivesbased on the model's estimate of consumer spending ability.

Referring now to FIGS. 1A, 1B, and 2-19, wherein similar components ofthe present disclosure are referenced in like manner, variousembodiments of a method and system for estimating the purchasing abilityof consumers will now be described in detail.

Turning now to FIG. 1A, there is depicted an exemplary computer network100 over which the transmission of the various types of consumer data asdescribed herein may be accomplished, using any of a variety ofavailable computing components for processing such data in the mannersdescribed below. Such components may include an institution computer102, which may be a computer, workstation or server, such as thosecommonly manufactured by IBM, and operated by a financial institution orthe like. The institution computer 102, in turn, has appropriateinternal hardware, software, processing, memory and networkcommunication components that enables it to perform the functionsdescribed here, including storing both internally and externallyobtained individual or aggregate consumer data in appropriate memory andprocessing the same according to the processes described herein usingprogramming instructions provided in any of a variety of useful machinelanguages. Institution computer 102 is described in further detail withrespect to FIG. 1B.

As shown in FIG. 1B, the institution computer 102 includes one or moreprocessors, such as processor 114. The processor 114 is connected to acommunication infrastructure 116 (e.g., a communications bus, cross-overbar, or network). Various software embodiments are described in terms ofthis exemplary computer system. After reading this description, it willbecome apparent to a person skilled in the relevant art(s) how toimplement the invention using other computer systems and/orarchitectures.

Institution computer 102 can include a display interface 112 thatforwards graphics, text, and other data from the communicationinfrastructure 116 (or from a frame buffer not shown) for display on thedisplay unit 140.

Institution computer 102 also includes a main memory 118, preferablyrandom access memory (RAM), and may also include a secondary memory 120.The secondary memory 120 may include, for example, a hard disk drive 122and/or a removable storage drive 124, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, etc. The removable storagedrive 124 reads from and/or writes to a removable storage unit 128 in awell known manner. Removable storage unit 128 represents a floppy disk,magnetic tape, optical disk, etc. which is read by and written to byremovable storage drive 124. As will be appreciated, the removablestorage unit 128 includes a computer usable storage medium having storedtherein computer software and/or data.

In alternative embodiments, secondary memory 120 may include othersimilar devices for allowing computer programs or other instructions tobe loaded into institution computer 102. Such devices may include, forexample, a removable storage unit 128 and an interface 130. Examples ofsuch may include a program cartridge and cartridge interface (such asthat found in video game devices), a removable memory chip (such as anerasable programmable read only memory (EPROM), or programmable readonly memory (PROM)) and associated socket, and other removable storageunits 128 and interfaces 130, which allow software and data to betransferred from the removable storage unit 128 to institution computer102.

Institution computer 102 may also include a communications interface134. Communications interface 134 allows software and data to betransferred between institution computer 102 and external devices.Examples of communications interface 134 may include a modem, a networkinterface (such as an Ethernet card), a communications port, a PersonalComputer Memory Card International Association (PCMCIA) slot and card,etc. Software and data transferred via communications interface 134 arein the form of signals 138 which may be electronic, electromagnetic,optical or other signals capable of being received by communicationsinterface 134. These signals 138 are provided to communicationsinterface 134 via a communications path (e.g., channel) 136. Thischannel 136 carries signals 138 and may be implemented using wire orcable, fiber optics, a telephone line, a cellular link, a radiofrequency (RF) link and other communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media such as removablestorage drive 124 and a hard disk installed in hard disk drive 122.These computer program products provide software to institution computer102. The invention is directed to such computer program products.

Computer programs (also referred to as computer control logic) arestored in main memory 118 and/or secondary memory 120. Computer programsmay also be received via communications interface 134. Such computerprograms, when executed, enable the institution computer 102 to performthe features of the present invention, as discussed herein. Inparticular, the computer programs, when executed, enable the processor114 to perform the features of the present invention. Accordingly, suchcomputer programs represent controllers of the institution computer 102.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intoinstitution computer 102 using removable storage drive 124, hard drive122 or communications interface 134. The control logic (software), whenexecuted by the processor 114, causes the processor 114 to perform thefunctions of the invention as described herein.

In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of the hardwarestate machine so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

The institution computer 102 may in turn be in operative communicationwith any number of other internal or external computing devices,including for example components 104, 106, 108, and 110, which may becomputers or servers of similar or compatible functional configuration.These components 104-110 may gather and provide aggregated andindividual consumer data, as described herein, and transmit the same forprocessing and analysis by the institution computer 102. Such datatransmissions may occur for example over the Internet or by any otherknown communications infrastructure, such as a local area network, awide area network, a wireless network, a fiber-optic network, or anycombination or interconnection of the same. Such communications may alsobe transmitted in an encrypted or otherwise secure format, in any of awide variety of known manners.

Each of the components 104-110 may be operated by either common orindependent entities. In one exemplary embodiment, which is not to belimiting to the scope of the present disclosure, one or more suchcomponents 104-110 may be operated by a provider of aggregate andindividual consumer tradeline data, an example of which includesservices provided by Experian Information Solutions, Inc. of Costa Mesa,Calif. (“Experian”). Tradeline level data preferably includes up to 24months or more of balance history and credit attributes captured at thetradeline level, including information about accounts as reported byvarious credit grantors, which in turn may be used to derive a broadview of actual aggregated consumer behavioral spending patterns.

Alternatively, or in addition thereto, one or more of the components104-110 may likewise be operated by a provider of individual andaggregate consumer panel data, such as commonly provided by comScoreNetworks, Inc. of Reston, Va. (“comScore”). Consumer panel data providesmore detailed and specific consumer spending information regardingmillions of consumer panel participants, who provide actual spend datato collectors of such data in exchange for various inducements. The datacollected may include any one or more of credit risk scores, onlinecredit card application data, online credit card purchase transactiondata, online credit card statement views, credit trade type and creditissuer, credit issuer code, portfolio level statistics, credit bureaureports, demographic data, account balances, credit limits, purchases,balance transfers, cash advances, payment amounts, finance charges,annual percentage interest rates on accounts, and fees charged, all atan individual level for each of the participating panelists. In variousembodiments, this type of data is used for model development, refinementand verification. This type of data is further advantageous overtradeline level data alone for such purposes, since such detailedinformation is not provided at the tradeline level. While such detailedconsumer panel data can be used alone to generate a model, it may not bewholly accurate with respect to the remaining marketplace of consumersat large without further refinement. Consumer panel data may also beused to generate aggregate consumer data for model derivation anddevelopment.

Additionally, another source of inputs to the model may be internalspend and payment history of the institution's own customers. From suchinternal data, detailed information at the level of specificity as theconsumer panel data may be obtained and used for model development,refinement and validation, including the categorization of consumersbased on identified transactor and revolver behaviors.

Turning now to FIG. 2, there is depicted a flowchart of an exemplaryprocess 200 for modeling aggregate consumer behavior in accordance withthe present disclosure. The process 200 commences at step 202 whereinindividual and aggregate consumer data, including time-series tradelinedata, consumer panel data and internal customer financial data, isobtained from any of the data sources described previously as inputs forconsumer behavior models. In certain embodiments, the individual andaggregate consumer data may be provided in a variety of different dataformats or structures and consolidated to a single useful format orstructure for processing.

Next, at step 204, the individual and aggregate consumer data isanalyzed to determine consumer spending behavior patterns. One ofordinary skill in the art will readily appreciate that the models mayinclude formulas that mathematically describe the spending behavior ofconsumers. The particular formulas derived will therefore highly dependon the values resulting from customer data used for derivation, as willbe readily appreciated. However, by way of example only and based on thedata provided, consumer behavior may be modeled by first dividingconsumers into categories that may be based on account balance levels,demographic profiles, household income levels or any other desiredcategories. For each of these categories in turn, historical accountbalance and transaction information for each of the consumers may betracked over a previous period of time, such as one to two years.Algorithms may then be employed to determine formulaic descriptions ofthe distribution of aggregate consumer information over the course ofthat period of time for the population of consumers examined, using anyof a variety of known mathematical techniques. These formulas in turnmay be used to derive or generate one or more models (step 206) for eachof the categories of consumers using any of a variety of available trendanalysis algorithms. The models may yield the following types ofaggregated consumer information for each category: average balances,maximum balances, standard deviation of balances, percentage of balancesthat change by a threshold amount, and the like.

Finally, at step 208, the derived models may be validated andperiodically refined using internal customer data and consumer paneldata from sources such as comScore. In various embodiments, the modelmay be validated and refined over time based on additional aggregatedand individual consumer data as it is continuously received by aninstitution computer 102 over the network 100. Actual customertransaction level information and detailed consumer information paneldata may be calculated and used to compare actual consumer spend amountsfor individual consumers (defined for each month as the differencebetween the sum of debits to the account and any balance transfers intothe account) and the spend levels estimated for such consumers using theprocess 200 above. If a large error is demonstrated between actual andestimated amounts, the models and the formulas used may be manually orautomatically refined so that the error is reduced. This allows for aflexible model that has the capability to adapt to actual aggregatedspending behavior as it fluctuates over time.

As shown in the diagram 300 of FIG. 3, a population of consumers forwhich individual and/or aggregated data has been provided may be dividedfirst into two general categories for analysis, for example, those thatare current on their credit accounts (representing 1.72 millionconsumers in the exemplary data sample size of 1.78 million consumers)and those that are delinquent (representing 0.06 million of suchconsumers). In one embodiment, delinquent consumers may be discardedfrom the populations being modeled.

In further embodiments, the population of current consumers is thensubdivided into a plurality of further categories based on the amount ofbalance information available and the balance activity of such availabledata. In the example shown in the diagram 300, the amount of balanceinformation available is represented by string of ‘+’ ‘0’ and ‘?’characters. Each character represents one month of available data, withthe rightmost character representing the most current months and theleftmost character representing the earliest month for which data isavailable. In the example provided in FIG. 3, a string of six charactersis provided, representing the six most recent months of data for eachcategory. The ‘+” character represents a month in which a credit accountbalance of the consumer has increased. The “0” character may representmonths where the account balance is zero. The “?” character representsmonths for which balance data is unavailable. Also provided the diagramis number of consumers fallen to each category and the percentage of theconsumer population they represent in that sample.

In further embodiments, only certain categories of consumers may beselected for modeling behavior. The selection may be based on thosecategories that demonstrate increased spend on their credit balancesover time. However, it should be readily appreciated that othercategories can be used. FIG. 3 shows the example of two categories ofselected consumers for modeling in bold. These groups show theavailability of at least the three most recent months of balance dataand that the balances increased in each of those months.

Turning now to FIG. 4, therein is depicted an exemplary diagram 400showing sub-categorization of the two categories of FIG. 3 in bold thatare selected for modeling. In the embodiment shown, the sub-categoriesmay include: consumers having a most recent credit balance less than$400; consumers having a most recent credit balance between $400 and$1600; consumers having a most recent credit balance between $1600 and$5000; consumers whose most recent credit balance is less than thebalance of, for example, three months ago; consumers whose maximumcredit balance increase over, for example, the last twelve monthsdivided by the second highest maximum balance increase over the sameperiod is less than 2; and consumers whose maximum credit balanceincrease over the last twelve months divided by the second highestmaximum balance increase is greater than 2. It should be readilyappreciated that other subcategories can be used. Each of thesesub-categories is defined by their last month balance level. The numberof consumers from the sample population (in millions) and the percentageof the population for each category are also shown in FIG. 4.

There may be a certain balance threshold established, wherein if aconsumer's account balance is too high, their behavior may not bemodeled, since such consumers are less likely to have sufficientspending ability. Alternatively, or in addition thereto, consumershaving balances above such threshold may be sub-categorized yet again,rather than completely discarded from the sample. In the example shownin FIG. 4, the threshold value may be $5000, and only those havingparticular historical balance activity may be selected, i.e. thoseconsumers whose present balance is less than their balance three monthsearlier, or whose maximum balance increase in the examined period meetscertain parameters. Other threshold values may also be used and may bedependent on the individual and aggregated consumer data provided.

As described in the foregoing, the models generated in the process 200may be derived, validated and refined using tradeline and consumer paneldata. An example of tradeline data 500 from Experian and consumer paneldata 502 from comScore are represented in FIG. 5. Each row of the data500, 502 represents the record of one consumer and thousands of suchrecords may be provided at a time. The statement 500 shows thepoint-in-time balance of consumers accounts for three successive months(Balance 1, Balance 2 and Balance 3). The data 502 shows each consumer'spurchase volume, last payment amount, previous balance amount andcurrent balance. Such information may be obtained, for example, by pagescraping the data (in any of a variety of known manners usingappropriate application programming interfaces) from an Internet website or network address at which the data 502 is displayed. Furthermore,the data 500 and 502 may be matched by consumer identity and combined byone of the data providers or another third party independent of thefinancial institution. Validation of the models using the combined data500 and 502 may then be performed, and such validation may beindependent of consumer identity.

Turning now to FIG. 6, therein is depicted an exemplary process 600 forestimating the size of an individual consumer's spending wallet. Uponcompletion of the modeling of the consumer categories above, the process600 commences with the selection of individual consumers or prospects tobe examined (step 602). An appropriate model derived during the process200 will then be applied to the presently available consumer tradelineinformation in the following manner to determine, based on the resultsof application of the derived models, an estimate of a consumer's sizeof wallet. Each consumer of interest may be selected based on theirfalling into one of the categories selected for modeling describedabove, or may be selected using any of a variety of criteria.

The process 600 continues to step 604 where, for a selected consumer, apaydown percentage over a previous period of time is estimated for eachof the consumer's credit accounts. In one embodiment, the paydownpercentage is estimated over the previous three-month period of timebased on available tradeline data, and may be calculated according tothe following formula:Pay-down %=(The sum of the last three months payments from theaccount)/(The sum of three month balances for the account based ontradeline data).The paydown percentage may be set to, for example, 2%, for any consumerexhibiting less than a 5% paydown percentage, and may be set to 100% ifgreater than 80%, as a simplified manner for estimating consumerspending behaviors on either end of the paydown percentage scale.

Consumers that exhibit less than a 50% paydown during this period may becategorized as revolvers, while consumers that exhibit a 50% paydown orgreater may be categorized as transactors. These categorizations may beused to initially determine what, if any, purchasing incentives may beavailable to the consumer, as described later below.

The process 600, then continues to step 606, where balance transfers fora previous period of time are identified from the available tradelinedata for the consumer. The identification of balance transfers areessential since, although tradeline data may reflect a higher balance ona credit account over time, such higher balance may simply be the resultof a transfer of a balance into the account, and are thus not indicativeof a true increase in the consumer's spending. It is difficult toconfirm balance transfers based on tradeline data since the informationavailable is not provided on a transaction level basis. In addition,there are typically lags or absences of reporting of such values ontradeline reports.

Nonetheless, marketplace analysis using confirmed consumer panel andinternal customer financial records has revealed reliable ways in whichbalance transfers into an account may be identified from imperfectindividual tradeline data alone. Three exemplary reliable methods foridentifying balance transfers from credit accounts, each which is basedin part on actual consumer data sampled, are as follows. It should bereadily apparent that these formulas in this form are not necessary forall embodiments of the present process and may vary based on theconsumer data used to derive them.

A first rule identifies a balance transfer for a given consumer's creditaccount as follows. The month having the largest balance increase in thetradeline data, and which satisfies the following conditions, may beidentified as a month in which a balance transfer has occurred:

-   -   The maximum balance increase is greater than twenty times the        second maximum balance increase for the remaining months of        available data;    -   The estimated pay-down percent calculated at step 306 above is        less than 40%; and    -   The largest balance increase is greater than $1000 based on the        available data.

A second rule identifies a balance transfer for a given consumer'scredit account in any month where the balance is above twelve times theprevious month's balance and the next month's balance differs by no morethan 20%.

A third rule identifies a balance transfer for a given consumer's creditaccount in any month where:

-   -   the current balance is greater than 1.5 times the previous        month's balance;    -   the current balance minus the previous month's balance is        greater than $4500; and    -   the estimated pay-down percent from step 306 above is less than        30%.

The process 600 then continues to step 608, where consumer spend on eachcredit account is estimated over the next, for example, three monthperiod. In estimating consumer spend, any spending for a month in whicha balance transfer has been identified from individual tradeline dataabove is set to zero for purposes of estimating the size of theconsumer's spending wallet, reflecting the supposition that no realspending has occurred on that account. The estimated spend for each ofthe three previous months may then be calculated as follows:Estimated spend=(the current balance−the previous month's balance+(theprevious month's balance*the estimated pay-down % from step 604 above).The exact form of the formula selected may be based on the category inwhich the consumer is identified from the model applied, and the formulais then computed iteratively for each of the three months of the firstperiod of consumer spend.

Next, at step 610 of the process 600, the estimated spend is thenextended over, for example, the previous three quarterly or three-monthperiods, providing a most-recent year of estimated spend for theconsumer.

Finally, at step 612, this in turn may be used to generate a pluralityof final outputs for each consumer account (step 314). These may beprovided in an output file that may include a portion or all of thefollowing exemplary information, based on the calculations above andinformation available from individual tradeline data: (i) size ofprevious twelve month spending wallet; (ii) size of spending wallet foreach of the last four quarters; (iii) total number of revolving cards,revolving balance, and average pay down percentage for each; (iv) totalnumber of transacting cards, and transacting balances for each; (v) thenumber of balance transfers and total estimated amount thereof; (vi)maximum revolving balance amounts and associated credit limits; and(vii) maximum transacting balance and associated credit limit.

After step 612, the process 600 ends with respect to the examinedconsumer. It should be readily appreciated that the process 600 may berepeated for any number of current customers or consumer prospects.

Referring now to FIGS. 7-10, therein is depicted illustrative diagrams700-1000 of how such estimated spending is calculated in a rollingmanner across each previous three month (quarterly) period. In FIG. 7,there is depicted a first three month period (i.e., the most recentprevious quarter) 702 on a timeline 710. As well, there is depicted afirst twelve-month period 704 on a timeline 708 representing the lasttwenty-one months of point-in-time account balance information availablefrom individual tradeline data for the consumer's account. Each month'sbalance for the account is designated as “B#.” B1-B12 represent actualaccount balance information available over the past twelve months forthe consumer. B13-B21 represent consumer balances over consecutive,preceding months.

In accordance with the diagram 700, spending in each of the three monthsof the first quarter 702 is calculated based on the balance valuesB1-B12, the category of the consumer based on consumer spending modelsgenerated in the process 200, and the formulas used in steps 604 and606.

Turning now to FIG. 8, there is shown a diagram 800 illustrating thebalance information used for estimating spending in a second previousquarter 802 using a second twelve-month period of balance information804. Spending in each of these three months of the second previousquarter 802 is based on known balance information B4-B15.

Turning now to FIG. 9, there is shown a diagram 900 illustrating thebalance information used for estimating spending in a third successivequarter 902 using a third twelve-month period of balance information904. Spending in each of these three months of the third previousquarter 902 is based on known balance information B7-B18.

Turning now to FIG. 10, there is shown a diagram 1000 illustrating thebalance information used for estimating spending in a fourth previousquarter 1002 using a fourth twelve-month period of balance information1004. Spending in each of these three months of the fourth previousquarter 1002 is based on balance information B10-B21.

It should be readily appreciated that as the rolling calculationsproceed, the consumer's category may change based on the outputs thatresult, and, therefore, different formula corresponding to the newcategory may be applied to the consumer for different periods of time.The rolling manner described above maximizes the known data used forestimating consumer spend in a previous twelve month period 1006.

Based on the final output generated for the customer, commensuratepurchasing incentives may be identified and provided to the consumer,for example, in anticipation of an increase in the consumer's purchasingability as projected by the output file. In such cases, consumers ofgood standing, who are categorized as transactors with a projectedincrease in purchasing ability, may be offered a lower financing rate onpurchases made during the period of expected increase in theirpurchasing ability, or may be offered a discount or rebate fortransactions with selected merchants during that time.

In another example, and in the case where a consumer is a revolver, suchconsumer with a projected increase in purchasing ability may be offereda lower annual percentage rate on balances maintained on their creditaccount.

Other like promotions and enhancements to consumers' experiences arewell known and may be used within the processes disclosed herein.

Various statistics for the accuracy of the processes 200 and 600 areprovided in FIGS. 11-18, for which a consumer sample was analyzed by theprocess 200 and validated using 24 months of historic actual spend data.The table 1100 of FIG. 11 shows the number of consumers having a balanceof $5000 or more for whom the estimated paydown percentage (calculatedin step 604 above) matched the actual paydown percentage (as determinedfrom internal transaction data and external consumer panel data).

The table 1200 of FIG. 12 shows the number of consumers having a balanceof $5000 or more who were expected to be transactors or revolvers, andwho actually turned out to be transactors and revolvers based on actualspend data. As can be seen, the number of expected revolvers who turnedout to be actual revolvers (80539) was many times greater than thenumber of expected revolvers who turned out to be transactors (1090).Likewise, the number of expected and actual transactors outnumbered bynearly four-to-one the number of expected transactors that turned out tobe revolvers.

The table 1300 of FIG. 13 shows the number of estimated versus actualinstances in the consumer sample of when there occurred a balancetransfer into an account. For instance, in the period sampled, therewere 148,326 instances where no balance transfers were identified instep 606 above, and for which a comparison of actual consumer datashowed there were in fact no balance transfers in. This compares to only9,534 instances where no balance transfers were identified in step 606,but there were in fact actual balance transfers.

The table 1400 of FIG. 14 shows the accuracy of estimated spending (insteps 608-612) versus actual spending for consumers with accountbalances (at the time this sample testing was performed) greater than$5000. As can be seen, the estimated spending at each spending levelmost closely matched the same actual spending level than for any otherspending level in nearly all instances.

The table 1500 of FIG. 15 shows the accuracy of estimated spending (insteps 608-612) versus actual spending for consumers having most recentaccount balances between $1600 and $5000. As can be readily seen, theestimated spending at each spending level most closely matched the sameactual spending level than for any other spending level in allinstances.

The table 1600 of FIG. 16 shows the accuracy of estimated spendingversus actual spending for all consumers in the sample. As can bereadily seen, the estimated spending at each spending level most closelymatched the same actual spending level than for any other actualspending level in all instances.

The table 1700 of FIG. 17 shows the rank order of estimated versusactual spending for all consumers in the sample. This table 1700 readilyshows that the number of consumers expected to be in the bottom 10% ofspending most closely matched the actual number of consumers in thatcategory, by 827,716 to 22,721. The table 1700 further shows that thenumber of consumers expected to be in the top 10% of spenders mostclosely matched the number of consumers who were actually in the top10%, by 71,773 to 22,721.

The table 1800 of FIG. 18 shows estimated versus actual annual spendingfor all consumers in the sample over the most recent year of availabledata. As can be readily seen, the expected number of consumers at eachspending level most closely matched the same actual spending level thanany other level in all instances.

Finally, the table 1900 of FIG. 19 shows the rank order of estimatedversus actual total annual spending for all the consumers over the mostrecent year of available data. Again, the number of expected consumersin each rank most closely matched the actual rank than any other rank.

Prospective customer populations used for modeling and/or laterevaluation may be provided from any of a plurality of availablemarketing groups, or may be culled from credit bureau data, targetedadvertising campaigns or the like. Testing and analysis may becontinuously performed to identify the optimal placement and requiredfrequency of such sources for using the size of spending walletcalculations. The processes described herein may also be used to developmodels for predicting a size of wallet for an individual consumer.

Institutions adopting the processes disclosed herein may expect to morereadily and profitably identify opportunities for prospect and customerofferings, which in turn provides enhanced experiences across all partsof a customer's lifecycle. In the case of a credit provider, accurateidentification of spend opportunities allows for rapid provisioning ofcard member offerings to increase spend that, in turn, results inincreased transaction fees, interest charges and the like. The carefulselection of customers to receive such offerings reduces the incidenceof fraud that may occur in less disciplined card member incentiveprograms. This, in turn, reduces overall operating expenses forinstitutions.

Household Size of Wallet

In addition to determining the size of wallet of a single consumer, theabove process may also be used in determining the size of wallet of agiven household. Determining the size of wallet of a household allows afinancial institution to more accurately estimate the spend opportunityassociated with an individual than would be estimated from theindividual's size of wallet alone. For example, two example consumersmay have the same individual size of wallet. However, one consumer issingle and lives alone, but the other consumer is married to a spousewhose size of wallet is twice as big as the second consumer. The secondconsumer thus has more spending potential than the first, even thoughthey look very similar when standing alone.

FIG. 20 is a flowchart of an exemplary method 2000 of determining thesize of wallet of an entire household. In step 2002, individualconsumers are grouped into households. A household may include, forexample, all people with credit bureau history that live at the sameaddress. Such individuals do not necessarily need to have the same lastname. The grouping may exclude certain people, such as those under theage of 18, or those who have opted out of direct marketing campaigns. Inaddition, address data may not necessarily be current or accurate. Thus,such embodiments that rely solely on grouping consumers at the sameaddress may not be as reliable as further embodiments described herein.In addition, as described below, grouping by residential address maylead to the presence of duplicate tradelines, which may be identifiedand removed to improve accuracy. Other methodologies, such as thosedescribed herein, lessen or eliminate the need for addressing duplicatetradelines.

In step 2004, once individual consumers are grouped into a household,tradelines held by one or more of the consumers in the household areidentified and associated with the household. The tradelines may bedetermined using, for example and without limitation, credit bureau dataand internal records of the financial institution.

In step 2006, duplicate tradelines are identified and removed fromassociation with the household, such that only unique trades remainassociated with the household. Duplicates occur when the basic user ofan account shares a household with a supplemental user of the sameaccount. To identify duplicate tradelines, the history is obtained forevery tradeline associated with the household. The history may belimited to a given timeframe, such as the previous 24 months. Thishistory may include, for example and without limitation, account balanceand transaction information. The histories of the tradelines are thencompared to determine if any tradeline in the household has the samehistorical performance as another tradeline in the household. If twotradelines are identified as having the same historical performance, oneof the tradelines is determined to be a duplicate, and is not consideredin the household size of wallet calculation.

In step 2008, an estimated spend capacity for each of the remaining,unique tradelines is calculated based on the balance of the tradeline.The estimated spend capacity may be calculated, for example, asdescribed with respect to method 600 (FIG. 6) above.

In step 2010, the estimated spend capacities of the unique tradelines inthe household are summed. The resulting combined spend capacity isoutput as the household size of wallet. The household size of wallet canthen be associated with each individual consumer in the household.

Once individual consumers are tagged with or otherwise identified bytheir household size of wallet, a financial institution can moreaccurately categorize the consumers and provide the consumers with morerelevant offers. For example, based on the household size of walletcalculated for an existing customer, purchasing incentives may beidentified and provided to the existing customer to encourage spend onan existing account. In another example, prospective customers may betargeted based on their own specific household sizes of wallet and/orspend characteristics of other consumers in their household. In thisexample, a prospective cardholder whose household size of wallet issignificantly higher than his individual size of wallet is expected tohave high spend and a high response rate to product offers. Similarly, aprospective cardholder that lives in the same household as a high spend,low risk card holder is expected to be high spend and low risk as well.Such targeting encourages spend by prospective cardholders on newaccounts.

Categorizing consumers by household type reveals trends which can beused to identify low risk prospects without completing size of walletanalyses for each specific prospect. The household size and mix ofconsumers therein defines a household type.

FIG. 21 is a chart identifying various household types 2102. Eachhousehold type 2102 has a particular size 2104 and a particular mix2106. Size 2104 corresponds to the number of consumers in the household.Mix 2106 corresponds to the number of basic cardholders, supplementalcardholders, and prospective cardholders in the household. Eachhousehold type makes up a percentage 2108 of all households.

FIG. 22 illustrates average sizes of wallet by household type. As wouldbe expected, household size of wallet increases as the number of peoplein a household increases, and depends on the mix of consumers in thehousehold. Of households with two people, for example, those having twobasic cardholders (type 2A) tend to have the largest wallet, whilehouseholds having one basic cardholder and one prospective cardholder(type 2C) tend to have the smallest wallet. In another example, ofhouseholds with three people, those having two basic cardholders and oneprospective cardholder (type 3C) tend to have the largest wallets(excluding the “other” category), while households having one basiccardholder and two prospective cardholders (type 3A) tend to have thesmallest wallets.

By identifying the types of households having the largest wallets, afinancial institution can target consumers in those household types withnew product offers and/or incentives on existing products to encouragespend with the financial institution by the consumers. For example, thefinancial institution can target prospective cardholders of all type-2Ahouseholds with an offer for a new card product that suits their needs,since those cardholders are the most likely to accept such an offerwhile maintaining a low risk of default.

Once the size of wallet has been determined for a given household, theshare of the household wallet held by a particular financial institutioncan also be determined. The share of wallet is the percentage of thetotal size of wallet that is associated with the financial institutionand can typically be determined, for example, from the internal recordsof the financial institution. By identifying households where thefinancial institution has only a small share of the household size ofwallet, the financial institution can determine which households offerthe best prospects for spending growth. This is referred to as the spendopportunity. Households having a large spend opportunity can then betargeted for product offers and incentives to increase spend by theconsumer with the financial institution. For example, for a financialinstitution having the exemplary share of household wallet distributionillustrated in FIG. 23, the greatest spend opportunity is available inhouseholds having one basic cardholder and one supplemental cardholder(type 2B) and households having one basic cardholder and one prospectivecardholder (type 2C).

Identifying Financial Relationships

As described above, the identification of financial relationships may bedifficult because credit bureaus at present do not associate tradelineswith debtors other than the primary debtor that is identifiable. Inaddition, grouping consumers solely by physical residential address is aless preferred method of determining a household, as it has thedisadvantages described above. Moreover, consumers have financialrelationships that transcend physical residential address. For example,a parent may co-sign for a credit card with a child who is a young adult(e.g., a child in college). A child may co-sign an automobile loan for aparent who would not be able to secure such a loan without a co-signor.Unmarried couples may share financial obligations despite maintainingseparate residences. Identifying types of financial relationships thatextend beyond a shared physical residential address may be used inimproving marketing, credit approval decisions, and other financialcalculations, a described herein. Thus, improved methods for identifyingand analyzing financial relationships are desirable.

Credit bureaus typically receive credit bureau reporting data (e.g., asreported using METRO 2) and populate debtor records associated with thetradeline. For example, a credit bureau reporting data in a METRO 2container may be received by a credit bureau. The credit bureau mayparse the Base Segment to identify the primary debtor and may furtherparse the J1 or J2 segments to identify a secondary debtor. The creditbureau may further parse the Base Segment to identify a secondarydebtor. The credit bureau may then update its records for the primarydebtor and update its records pertaining to the secondary debtor, but,conventionally, no linkage between the debtors is made. The creditbureau reporting data (e.g., the METRO 2 container) is conventionallypurged after the debtor records are updated. Thus, one cannot query forall debtors associated with that tradeline by using the tradeline data.Stated another way, one may not identify all debtors associated with agiven tradeline. One could not identify financial relationships, then,from present credit bureau records.

In various embodiments, a credit bureau may receive credit bureaureporting data and create a linkage (also referred to as a link) betweenthe tradeline and the debtors associated with the tradeline. Such alinkage may take the form of a combination (e.g., concatenation), of twoor more fields from a tradeline. Stated another way, the linkage may bea numeric or alphanumeric representation of the tradeline that is uniqueor likely unique to that tradeline. In this manner, the linkage may beproduced from data related to the tradeline that are static over time(such as trade open date), but the linkage may also be produced fromdata related to the tradeline that is dynamic over time (such as thehigh credit field). In various embodiments, a linkage may comprise acombination or concatenation of subscriber code and account number. Forexample, a tradeline with subscriber code “1234” and account number“567” may be concatenated to produce the linkage “1234567.” In thatregard, it is likely that, across a tradeline, very few if any will havethe same linkage value. Other fields that may be used in the linkage maybe the last update date, trade open date, and balance. In variousembodiments, to increase the likelihood that the linkage will be uniquefor each tradeline and/or to assist in obscuring the underlying data, ahash function, cryptographic function, or other similar function may beused to transform the linkage into another form. Thus, in variousembodiments, a cryptographic function is used to “hide” the subscribercode and account number in a linkage such that one could not, withoutpossession of the cryptographic function, obtain the unencryptedlinkage.

Accordingly, the link could be used to query for tradelines associatedwith two or more debtors. For example, a reference or pointer may beassociated with the tradeline that references the primary and secondarydebtor. In that regard, a data store may be queried to identify atradeline and then associate primary and secondary debtors. Accordingly,given a tradeline, one may find the associated debtors.

By retaining a linkage between a primary and a secondary debtor and atradeline obtained from credit reporting data, it is understood thatsuch linkage is of high accuracy. Stated another way, one may be nearlycertain that the tradeline is, in fact, associated with the primarydebtor and the secondary debtor, as the only source of inaccuracy may befrom the entity that is providing the credit reporting data. Thus, thelinkage contained in the credit reporting data may be considereddefinitive.

With reference to FIG. 24, method 2400 is illustrated. Credit reportingdata may be received in step 2402. Credit reporting data may be in aMETRO 2 container. The credit reporting data may be parsed in step 2404.Parsing may occur using any suitable method or parser. In embodimentswhere a METRO 2 container is used, the parsing may be of the BaseSegment, the J1 Segment, the J2 Segment, or combinations thereof. TheBase Segment, the J1 Segment, or the J2 Segment may contain datarelating to a secondary debtor associated with the tradeline reported inthe METRO 2 container, such as co-debtor name, address, and age, alongwith data relating to one or more additional debtors. The Base Segmentmay contain a generation code (GEN code) that contains information onthe number of co-debtors on a tradeline. The J1 and/or J2 segments maycontain similar information. It should be understood that the METRO 2container may have an analog provided in an XML format, and thus thedisclosure herein is not limited to a METRO 2 container that comprises adelimited or fixed width file. A link may be created in step 2406 thatlinks the tradeline with one or more co-debtors derived from parsingstep 2404. For example, step 2406 may comprise obtaining the subscribercode and the account number from the METRO 2 container. Step 2046 mayfurther comprise combining (e.g., concatenating) the subscriber code andthe account number to create a linkage. Optionally in step 2046, thelinkage may be encrypted or otherwise transformed to a different datavalue.

With reference to FIG. 28, method 2800 is illustrated. A METRO 2container may be received in step 2802. Parsing of the METRO 2container, including parsing the J1 Segment, the J2 Segment, and/or theBase Segment is performed in step 2804. A link may be created in step2806 that links the tradeline described in the METRO 2 container withone or more co-debtors derived from parsing step 2804.

In various embodiments, however, credit bureau data may exist in a datastore that does not contain such link. For example, this may occur wherethe credit bureau did not retain the linkage between a tradeline and aprimary and secondary debtor. Thus, other methods may be employed toidentify financial relationships with a higher degree of accuracy.

In various embodiments, a tradeline may be used to produce a fingerprintand the fingerprint may be used to query for associated debtors. Atradeline contains tradeline data, such as original balance amount,current balance, payment history, origination date, credit issuer name,and other like data. Two or more data fields from the tradeline data maybe selected for the creation of a fingerprint. A fingerprint, such as adigital fingerprint, is a mathematical representation of the input data.A fingerprint algorithm, similar to a hash function, for example, may beused to insure that different input data produces a differentfingerprint. Thus, a fingerprint algorithm may be used to make sure thatno two fingerprints are the same, unless the input data is the same.Fingerprint algorithms may be used and/or hash functions, checksumfunctions, and randomization functions, among others.

For example, debtor A may have a tradeline with credit issuer Bank X,originated on Jul. 29, 2006, having an opening balance of thirtythousand dollars and a current balance of ten thousand dollars. Afingerprint algorithm may be used to produce a digital output (i.e., anumber) that represents a fingerprint of these inputs. The tradelines ofother debtors may then be queried. It may then be found that debtor Band debtor C have tradelines with the same fingerprint. Thus, it islikely that debtor B and debtor C are associated with the tradeline andthe records associated with debtor B and debtor C may be updated toreflect the association. In various embodiments, multiple fingerprintsmay be made using varying input data fields. In the above example, analternate fingerprint may be created using credit issuer Bank X,originated on Jul. 29, 2006, having an opening balance of thirtythousand dollars, a current balance of ten thousand dollars, and thepresence of a missed or late payment in March 2009. Querying thealternate fingerprint may return only debtor B, thus indicating thatdebtor C may have a similar, but not identical, tradeline as debtors Aand B. The use of one or more alternate fingerprints may improveaccuracy.

For example, with reference to FIG. 26, method 2600 is illustrated. Atradeline may be identified in step 2602. A fingerprint may be generatedfor the tradeline in step 2604. The fingerprint may be generated byselecting one or more data points from the tradeline and processing thedata points through a fingerprint algorithm to produce a digitalfingerprint. Step 2604 may be generated for many tradelines in a datastore for a number of debtors. The digital fingerprint may then be usedto retrieve other debtors who may have tradelines with identicalfingerprints in step 2604.

Use of a fingerprint may be highly accurate, though not as accurate asdefinitive knowledge of a link such as would be obtained in creditreporting data. Thus, use of a fingerprint may be performed on a datastore containing credit bureau data to identify common tradelines andlink co-debtors together. Then, upon receipt of credit reporting data onthe tradeline, the credit reporting data may be parsed to reveal one ormore associated debtors. The credit reporting data may be compared tothe linkages created through the use of a fingerprint. Linkages may bemodified (i.e., deleted or edited) in response to the credit reportingdata. This improves accuracy, as well as provides an accuracy metricrelative to the type of fingerprint methodology used. For example, theaccuracy metric may comprise the percentage of linkages found in creditreporting data from the total number of linkages identified by use of afingerprint.

Linkages between debtors may reveal a debtor entity. A debtor entity maybe defined as one or more persons that are liable on a tradeline (i.e.,co-signer, etc). For example, a married couple comprising debtor A anddebtor B form a debtor entity. The debtor entity may then be queriedagainst, for example, a data store comprising credit bureau data toreturn all tradelines associated with the debtor entity. The returneddata may be referred to as household tradeline data. In variousembodiments, expanded household tradeline data includes tradelinesassociated with debtor A and debtor B, but also tradelines associatedwith debtor A only and debtor B only. The expanded household tradelinedata thus provides a more comprehensive picture of the union of debtor Aand debtor B, whereas household tradeline data provides an insight intohow debtor A and debtor B behave as a debtor entity. In variousembodiments, household tradeline data and expanded household tradelinedata may comprise data from debtors that do not reside at the samephysical address. Thus, the term “household” in this term is used forconvenience only.

To demonstrate household tradeline data and expanded household tradelinedata and with reference to FIG. 25, Venn diagram 2500 is shown. Area2502 includes all tradelines of a first debtor. Area 2504 includes alltradelines of a second debtor. Area 2506 shows the intersection of area2502 and area 2504, representing the household tradeline data, or thetradelines that are associated with both the first debtor and seconddebtor. The union of area 2502 and 2504 (which includes area 2506), maycomprise expanded household tradeline data.

Thus, it may be found that household tradeline data provides a pictureof stable debtors with little to no negative payment histories butexpanded household tradeline data may show that one or more of theunderlying debtors has separate tradelines that have a negative history.This may be the case for a couple where one or more spouses haspreviously divorced. The divorced spouse may have negative credithistory on separate accounts but positive credit history on accountswhere joined by the present spouse.

In various embodiments, debtors that are associated with a tradeline mayhave different physical residential addresses. The demographic data fromthe different residential addresses may be obtained to improve variousactivities, such as marketing and collection efforts. Demographic datamay include ZIP+4 of residential address, census data (e.g., number ofpeople, income levels, etc), and data relating to the number and typesof businesses in the ZIP+4 or other geographic descriptor (e.g., numberof big box discount stores, number of liquor stores, pawn shops, adultentertainment venues, non-bank check cashing stores, car title loanstores, non-bank, unsecured loan stores, number of public housingprojects, number of luxury goods retailers, etc). Demographic data maybe used as described, below.

To further collect data relating to financial relationships, contactinformation may be collected from various debtors, such as through asocial networking site, a cloud service (e.g., ICLOUD) or through amobile smartphone application (an “app”). The collection of contactinformation may be merged with debtor records to provide furtherinformation regarding a debtor's co-debtors and the familial or maritalrelationship. For example, it a debtor stores a contact labeled “wife”and the debtor is also linked to a mortgage tradeline associated withthe person labeled “wife,” it may be inferred that the co-debtor is thedebtor's wife. In various embodiments, a debtor's contact list maycontain contacts that do not have existing tradelines such as, forexample, minor children. Such contacts may be referred to as unmatcheddebtor records. The relationship to the debtor may preserved in a recordfor the unmatched debtor. At a later time, when the unmatched debtoropens a tradeline (e.g., a minor child reaches adulthood and open atransaction account), the unmatched debtor may be linked to the debtor.

Uses of Financial Relationship Information

Outputs of the disclosed financial relationship identification (the “FRImodel”) can be used in various analytics and may provide improvedmarketing and collection activities, among other activities.

A method of marketing 2700 is illustrated in FIG. 27. A second debtor ona tradeline associated with a first debtor may be identified using oneor more of the methods disclosed above in step 2702. The second debtormay then be the subject of marketing in step 2704. The products orservices marketed may be similar to the tradeline associated with afirst debtor. In various embodiments, however, internal data is obtainedrelating to the first debtor and/or the second debtor. The internal datamay be analyzed to determine the spending behaviors of the first debtorand/or the second debtor. Thus, the spending behavior of the firstdebtor may be used to tailor the marketing to the second debtor. Themarketing of step 2704 may be distributed to the first debtor yettargeted to the second debtor. For example, if internal data is used toshow that the second debtor shops at a particular store every week,marketing material promoting the store or the store's competitor may besent to the first debtor with the intention that the first debtor willbe aware of the second debtor's affinity for the store (or the seconddebtor's desire to try a new competing store) and share it with thesecond debtor. In this manner, the social networking power may amplifythe marketing message. Stated another way, marketing is more likely toresult in a sale when it originates from a person the marketing targetknows. In this case, co-debtors often have a close relationship, such asmarried couples, parents and children, and other forms of relationships.The marketing may comprise an offer to add the second debtor to atradeline of the first debtor. For example, where a first debtor and asecond debtor are linked to a mortgage tradeline, it may be found thatfirst debtor has a tradeline for a transaction account from creditissuer A and second debtor has a tradeline for a transaction accountfrom credit issuer B. Credit issuer A may be then provide an incentivefor the first debtor to add the second debtor to the first debtor'stransaction account. This may be especially useful if the seconddebtor's size of wallet is large relative to the first debtor and/or ifthe credit issuer has a small share of wallet relative to the seconddebtor.

A method of using internal data 2900 is shown in FIG. 29. As discussedabove, one may identify a household tradeline data set or an expandedhousehold tradeline data set in step 2902. One may then obtain internaldata relating to the debtors in the household data set. Spendingpatterns may be determined in step 2906 using the internal data. In thisregard, a spending profile may be built. The spending profile may beused to tailor marketing to the underlying debtors on a householdtradeline data set or an expanded household tradeline data set. Forexample, a “daily deal” type campaign may be submitted to the debtorswho are linked by a tradeline for a daily deal in the area of a sharedresidence. The daily deal may be a business or a type of businessfrequented by one or more of the debtors. For example, a pizza shop or acoffee shop that competes with a similar business frequented by one ormore the debtors may want to promote itself by offering such a dailydeal in a targeted manner.

Use of internal data may be especially useful with financialrelationships that extend between two people that do not reside at thesame physical address. For example, it may be found that a parent sharesa transaction account with a child who attends college in a differentstate or region from the parent. Thus, marketing to the child will beage appropriate (e.g., youth oriented brands, bars/nightclubs, and youthoriented entertainment) and in accordance with the spending patterns ofboth the child and parent. Thus, a child with a parent who has a largesize of wallet may be marketed with more upscale goods and services. Achild with a parent who dines out often may thus be accustomed to diningout, and may thus be the subject of restaurant marketing. On the otherhand, a child who has a parent that purchases more groceries and dinesout less may be accustomed to such a lifestyle and may be the subject ofmarketing for grocery stores that match the parent's grocery shoppinghabits (i.e., children of parents who shop at WHOLE FOODS will receivemarketing for TRADER JOE'S or SPROUTS or WHOLE FOODS). Complimentarygoods and services may also be marketed to the child. In addition, achild's transaction account may be linked to a parent. The child'sspending patterns may the be used to market goods and services to theparent, in addition to use of the parent's demographic information andinternal data associated with the parent.

Where two debtors are associated with the same tradeline and do notreside in the same physical address, demographic data for each debtormay be used in marketing, collection efforts, and other efforts. Forexample, when a primary debtor lives in a different type of area thanthe secondary debtor (e.g., the secondary debtor live in a ZIP+4 with ahigh number of businesses associated with risky behaviors), the primarydebtor may be deemed to be less creditworthy. On the other hand, thesecondary debtor may be deemed to be more creditworthy, as the secondarydebtor has a relationship with a more financially stable person. Inaddition, local businesses may be market to the secondary debtor becauseof the financial relationship with the first debtor.

A size of wallet calculation, as described herein, may be performed ondebtors who share one or more tradelines. In this manner, a size ofwallet of a debtor entity may be determined. Marketing activities may beperformed in response to this calculation. In addition, collectionefforts may be tailored in response to this calculation. For example, ifa first debtor is not current on a tradeline but it is found that thefirst debtor is linked to a second debtor that has a high size of walletor otherwise has a good credit history, aggressive collection effortsmay be warranted against the first debtor. In this manner, it may beexpected that the first debtor will seek to further the financialrelationship with the second debtor by asking the second debtor for helpwith respect to the tradeline in collections. In addition, the firstdebtor may use a credit line already shared with the second debtor tosettle the tradeline in collections. For example, the first debtor mayuse a home equity line of credit secured by the home of the seconddebtor to settle the tradeline in collections. However, if the seconddebtor has a low size of wallet or has negative credit history,aggressive collection efforts may not result in a recovery ofsubstantial funds.

A credit score may be derived for a debtor entity based upon either ahousehold tradeline data set or an expanded household tradeline dataset. The credit score may be formulated to be forward-looking, in thatit is useful in predicting default on future debt obligations, or it maybe backward-looking in that it is useful in predicting default onexisting debt obligations. Predicting default on future debt obligationsmay be useful in making credit approval decisions. Predicting default onexisting debt obligations may be useful in the buying or selling of debtobligations and/or securities derived from the same.

The credit score may be derived using any suitable methodology. Thecredit score may be based on either the household tradeline data set oran expanded household tradeline data set. In this regard, as describedabove, it may be found that certain underlying debtors do not meet debtobligations they have alone but do meet debt obligations they share withothers. Thus, a debtor entity may be relatively creditworthy while oneor more of the constituent debtors of the debtor entity may not becreditworthy.

A credit score that is predictive of default on existing debtobligations may be useful in the buying and selling of debt obligations.For example, an installment loan such as automobile loans may be bundledas an asset-back security, as mortgage loans may be as well. A purchaserof an asset back security interest may want to assess the stability ofthe underlying debt obligations. The use of a credit score may assist inthat regard and the added insight relating to shared or linked debtobligations may improve the accuracy of the credit score.

Credit approval decisions may be based, at least in part, on a creditscore as discussed above or by household tradeline data set or anexpanded household tradeline data set. Credit approval decisions may befor a new transaction account, a credit limit increase on an exitingtransaction account, a mortgage loan, an automobile loan, a home equityloan, or a student loan.

Uses of Financial Relationship Information by Industry

Outputs of the FRI model can be used in any business or market segmentthat extends credit or otherwise evaluates the creditworthiness of aparticular consumer. In various embodiments, these businesses will bereferred to herein as falling into one of three categories: financialservices companies, retail companies, and other companies.

The business cycle in each category may be divided into three phases:acquisition, retention, and disposal. The acquisition phase occurs whena business is attempting to gain new consumers. The acquisition phaseincludes, for example, targeted marketing, determining what products orservices to offer a consumer, deciding whether to lend to a particularconsumer and what the line size or loan should be, and deciding whetherto buy a particular loan. The retention phase occurs after a consumer isalready associated with the business. In the retention phase, thebusiness interests shift to managing the consumer relationship through,for example, consideration of risk, determination of credit lines,cross-sell opportunities, increasing business from that consumer, andincreasing the company's assets under management.

The disposal phase is entered when a business wishes to dissociateitself from a consumer or otherwise end the consumer relationship. Thedisposal phase can occur, for example, through settlement offers,collections, and sale of defaulted or near-default loans.

Financial services companies include, for example: banks and otherlenders, mutual fund companies, financiers of leases and sales, lifeinsurance companies, online brokerages, credit issuers, and loan buyers.

Banks and lenders can utilize the FRI model in all phases of thebusiness cycle. One exemplary use is in relation to home equity loansand the rating given to a particular bond issue in the capital market.The FRI model would apply to home equity lines of credit and automobileloans in a similar manner.

For example, if the holder of a home equity loan borrows from thecapital market, the loan holder issues asset-backed securities (“ABS”),or bonds, which are backed by receivables. The loan holder is thus anABS issuer. The ABS issuer applies for an ABS rating, which is assignedbased on the credit quality of the underlying receivables. One of skillin the art will recognize that the ABS issuer may apply for the ABSrating through any application means without altering the spirit andscope of the present invention. In assigning a rating, the ratingagencies weigh a loan's probability of default by considering thelender's underwriting and portfolio management processes. Lendersgenerally secure higher ratings by credit enhancement. Examples ofcredit enhancement include over-collateralization, buying insurance(such as wrap insurance), and structuring ABS (through, for example,senior/subordinate bond structures, sequential pay vs. pari passu, etc.)to achieve higher ratings. Lenders and rating agencies take theprobability of default into consideration when determining theappropriate level of credit enhancement.

During the acquisition phase of a loan, lenders may use the FRI model toimprove their lending decisions. Before issuing the loan, lenders canevaluate a consumer's risk of default using the consumer's associationswith various other lenders. Evaluation leads to fewer bad loans and areduced probability of default for loans in the lender's portfolio. Alower probability of default means that, for a given loan portfolio thathas been originated using the FRI model, either a higher rating can beobtained with the same degree of over-collateralization, or the degreeof over-collateralization can be reduced for a given debt rating. Thus,using the FRI model at the acquisition stage of the loan reduces thelender's overall borrowing cost and loan loss reserves.

During the retention phase of a loan, the FRI model can be used to tracka consumer's varying degree of risk. Based on the FRI outputs, thelender can make various decisions regarding the consumer relationship.For example, a lender may use the FRI model to identify borrowers whobecome more likely to default via the borrowers' association with otherlenders. The credit lines of those borrowers which have not fully beendrawn down can then be reduced. Selectively revoking unused lines ofcredit may reduce the probability of default for loans in a givenportfolio and reduce the lender's borrowing costs. Selectively revokingunused lines of credit may also reduce the lender's risk by minimizingfurther exposure to a borrower that may already be in financialdistress.

During the disposal phase of a loan, the FRI model enables lenders tobetter predict the likelihood that a borrower will default. Once thelender has identified consumers who are in danger of default, the lendermay select those likely to repay and extend settlement offers.Additionally, lenders can use the FRI model to identify which consumersare unlikely to pay and those who are otherwise not worth extending asettlement offer.

The FRI model allows lenders to identify loans with risk of default,allowing lenders, prior to default, to begin anticipating a course ofaction to take if default occurs. Because freshly defaulted loans fetcha higher sale price than loans that have been non-performing for longertime periods, lenders may sell these loans earlier in the defaultperiod, thereby reducing the lender's costs.

Financiers of leases or sales, such as automobile lease or salefinanciers, can benefit from FRI outputs in much the same way as a bankor lender, as discussed above. In typical product financing, however,the amount of the loan or lease is based on the value of the productbeing financed. Therefore, there is generally no credit limit that needsto be revisited during the course of the loan. As there is no creditlimit to be revisited, the FRI model is most useful to lease/salesfinance companies during the acquisition and disposal phases of thebusiness cycle.

Just as the FRI model can help loan holders determine that a particularloan is nearing default, loan buyers can use the model to evaluate thequality of a prospective purchase during the acquisition phase of thebusiness cycle. Evaluation assists the loan buyers in avoiding orreducing the sale prices of loans that are in likelihood of defaultbased on the consumer's association with other lenders.

Aspects of the retail industry for which the FRI model would beadvantageous include, for example: retail stores having private labelcards, on-line retailers, and mail order companies.

There are two general types of credit and charge cards in themarketplace today: multipurpose cards and private label cards. A thirdtype of hybrid card is emerging. Multipurpose cards are cards that canbe used at multiple different merchants and service providers. Forexample, American Express, Visa, Mastercard, and Discover are consideredmultipurpose card issuers. Multipurpose cards are accepted by merchantsand other service providers in what is often referred to as an “opennetwork.” Transactions are routed from a point-of-sale (“POS”) through anetwork for authorization, transaction posting, and settlement.

A variety of intermediaries play different roles in the process. Theseinclude merchant processors, the brand networks, and issuer processors.An open network is often referred to as an interchange network.Multipurpose cards include a range of different card types, such ascharge cards, revolving cards, and debit cards, which are linked to aconsumer's demand deposit account (“DDA”) or checking account.

Private label cards are cards that can be used for the purchase of goodsand services from a single merchant or service provider. Historically,major department stores were the originators of private label cards.Private label cards are now offered by a wide range of retailers andother service providers. These cards are generally processed on a closednetwork, with transactions flowing between the merchant's POS and itsown backoffice or the processing center for a third-party processor.These transactions do not flow through an interchange network and arenot subject to interchange fees.

Recently, a type of hybrid card has evolved. A hybrid card, when used ata particular merchant, is that merchant's private label card, but whenused elsewhere, becomes a multipurpose card. The particular merchant'stransactions are processed in the proprietary private label network.Transactions made with the card at all other merchants and serviceproviders are processed through an interchange network.

Private label card issuers, in addition to multipurpose card issuers andhybrid card issuers, can apply the FRI model in a similar way asdescribed above with respect to credit card companies. Knowledge of aconsumer's association with other lenders, coupled with FRI outputs,could be used by card issuers to improve performance and profitabilityacross the entire business cycle.

Online retail and mail order companies can use the FRI model in both theacquisition, and retention phases of the business cycle. During theacquisition phase, for example, the companies can base targetedmarketing strategies on FRI outputs.

Targeted marketing could substantially reduce costs, especially in themail order industry, where catalogs are typically sent to a wide varietyof individuals. During the retention phase, companies can, for example,base cross-sell strategies or credit line extensions on FRI outputs.

Types of companies which also may make use of the FRI model include, forexample and without limitation: the gaming industry, communicationsproviders, and the travel industry.

The gaming industry can use the FRI model in, for example, theacquisition and retention phases of the business cycle. Casinos oftenextend credit to their wealthiest and/or most active players, also knownas “high rollers.” The casinos can use the FRI model in the acquisitionphase to determine whether credit should be extended to an individual.Once credit has been extended, the casinos can use the FRI model toperiodically review the consumer's risk of default.

Communications providers, such as telephone service providers, oftencontract into service plans with their consumers. In addition toimproving their targeted marketing strategies, communications providerscan use the FRI outputs during the acquisition phase to determine therisk of default on a service contract associated with a potentialconsumer.

Members of the travel industry can make use of the FRI outputs in theacquisition and retention stages of the business cycle. For example, ahotelier typically has a brand of hotel that is associated with aparticular “star-level” or class of hotel. In order to capture variousmarket segments, hoteliers may be associated with several hotel brandsthat are of different classes. During the acquisition phase of thebusiness cycle, a hotelier may use the FRI outputs to target individualsthat have appropriate spend capacities for various classes of hotels.During the retention phase, the hotelier may use the FRI outputs todetermine, for example, when a particular individual's risk of defaultdecreases. Based on that determination, the hotelier can market a higherclass of hotel to the consumer in an attempt to convince the consumer toupgrade.

One of skill in the relevant art(s) will recognize that many of theabove described FRI applications may be utilized by other industries andmarket segments without departing from the spirit and scope of thepresent invention. For example, the strategy of using FRI to model anindustry's “best consumer” and targeting individuals sharingcharacteristics of that best consumer can be applied to nearly allindustries. FRI data can also be used across nearly all industries toimprove consumer loyalty by reducing the number of payment reminderssent to responsible accounts.

Responsible accounts include those who are most likely to pay evenwithout being contacted by a collector. The reduction in reminders mayincrease consumer loyalty, because the consumer will not feel that thelender or service provider is unduly aggressive. The lender's or serviceprovider's collection costs are also reduced, and resources are freed todedicate to accounts requiring more persuasion.

Additionally, the FRI model may be used in any company having a largeconsumer service call center to identify specific types of consumers.Transcripts are typically made for any call from a consumer to a callcenter. These transcripts may be scanned for specific keywords ortopics, and combined with the FRI model to determine the consumer'scharacteristics. For example, a bank having a large consumer servicecenter may scan service calls for discussions involving bankruptcy. Thebank could then use the FRI model with the indications from the callcenter transcripts to evaluate the consumer.

In various embodiments, the methods described herein are implementedusing the various particular machines described herein. The methodsdescribed herein may be implemented using the below particular machines,and those hereinafter developed, in any suitable combination, as wouldbe appreciated immediately by one skilled in the art. Further, as isunambiguous from this disclosure, the methods described herein mayresult in various transformations of certain articles.

For the sake of brevity, conventional data networking, applicationdevelopment and other functional aspects of the systems (and componentsof the individual operating components of the systems) may not bedescribed in detail herein. Furthermore, the connecting lines shown inthe various figures contained herein are intended to represent exemplaryfunctional relationships and/or, physical couplings between the variouselements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical system.

The various system components discussed herein may include one or moreof the following: a host server or other computing systems including aprocessor for processing digital data; a memory coupled to the processorfor storing digital data; an input digitizer coupled to the processorfor inputting digital data; an application program stored in the memoryand accessible by the processor for directing processing of digital databy the processor; a display device coupled to the processor and memoryfor displaying information derived from digital data processed by theprocessor; and a plurality of databases. Various databases used hereinmay include: client data; merchant data; financial institution data;and/or like data useful in the operation of the system. As those skilledin the art will appreciate, user computer may include an operatingsystem (e.g., Windows NT, Windows 95/98/2000, Windows XP, Windows Vista,Windows 7, OS2, UNIX, Linux, Solaris, MacOS, etc.) as well as variousconventional support software and drivers typically associated withcomputers. A user may include any individual, business, entity,government organization, software and/or hardware that interact with asystem.

A web client includes any device (e.g., personal computer) whichcommunicates via any network, for example such as those discussedherein. Such browser applications comprise Internet browsing softwareinstalled within a computing unit or a system to conduct onlinetransactions and/or communications. These computing units or systems maytake the form of a computer or set of computers, although other types ofcomputing units or systems may be used, including laptops, notebooks,hand held computers, personal digital assistants, set-top boxes,workstations, computer-servers, main frame computers, mini-computers, PCservers, pervasive computers, network sets of computers, personalcomputers, such as iPads, iMACs, and MacBooks, kiosks, terminals, pointof sale (POS) devices and/or terminals, televisions, or any other devicecapable of receiving data over a network. A web-client may run MicrosoftInternet Explorer, Mozilla Firefox, Google Chrome, Apple Safari, or anyother of the myriad software packages available for browsing theinternet.

Practitioners will appreciate that a web client may or may not be indirect contact with an application server. For example, a web client mayaccess the services of an application server through another serverand/or hardware component, which may have a direct or indirectconnection to an Internet server. For example, a web client maycommunicate with an application server via a load balancer. In anexemplary embodiment, access is through a network or the Internetthrough a commercially-available web-browser software package.

As those skilled in the art will appreciate, a web client includes anoperating system (e.g., Windows NT, 95/98/2000/CE/Mobile, OS2, UNIX,Linux, Solaris, MacOS, PalmOS, etc.) as well as various conventionalsupport software and drivers typically associated with computers. A webclient may include any suitable personal computer, network computer,workstation, personal digital assistant, cellular phone, smart phone,minicomputer, mainframe or the like. A web client can be in a home orbusiness environment with access to a network. In an exemplaryembodiment, access is through a network or the Internet through acommercially available web-browser software package. A web client mayimplement security protocols such as Secure Sockets Layer (SSL) andTransport Layer Security (TLS). A web client may implement severalapplication layer protocols including http, https, ftp, and sftp.

In an embodiment, various components, modules, and/or engines of system100 may be implemented as micro-applications or micro-apps. Micro-appsare typically deployed in the context of a mobile operating system,including for example, a Palm mobile operating system, a Windows mobileoperating system, an Android Operating System, Apple iOS, a Blackberryoperating system and the like. The micro-app may be configured toleverage the resources of the larger operating system and associatedhardware via a set of predetermined rules which govern the operations ofvarious operating systems and hardware resources. For example, where amicro-app desires to communicate with a device or network other than themobile device or mobile operating system, the micro-app may leverage thecommunication protocol of the operating system and associated devicehardware under the predetermined rules of the mobile operating system.Moreover, where the micro-app desires an input from a user, themicro-app may be configured to request a response from the operatingsystem which monitors various hardware components and then communicatesa detected input from the hardware to the micro-app.

As used herein, the term “network” includes any cloud, cloud computingsystem or electronic communications system or method which incorporateshardware and/or software components. Communication among the parties maybe accomplished through any suitable communication channels, such as,for example, a telephone network, an extranet, an intranet, Internet,point of interaction device (point of sale device, personal digitalassistant (e.g., iPhone®, Palm Pilot®, Blackberry®), cellular phone,kiosk, etc.), online communications, satellite communications, off-linecommunications, wireless communications, transponder communications,local area network (LAN), wide area network (WAN), virtual privatenetwork (VPN), networked or linked devices, keyboard, mouse and/or anysuitable communication or data input modality. Moreover, although thesystem is frequently described herein as being implemented with TCP/IPcommunications protocols, the system may also be implemented using IPX,Appletalk, IP-6, NetBIOS, OSI, any tunneling protocol (e.g. IPsec, SSH),or any number of existing or future protocols. If the network is in thenature of a public network, such as the Internet, it may be advantageousto presume the network to be insecure and open to eavesdroppers.Specific information related to the protocols, standards, andapplication software utilized in connection with the Internet isgenerally known to those skilled in the art and, as such, need not bedetailed herein. See, for example, DILIP NAIK, INTERNET STANDARDS ANDPROTOCOLS (1998); JAVA 2 COMPLETE, various authors, (Sybex 1999);DEBORAH RAY AND ERIC RAY, MASTERING HTML 4.0 (1997); and LOSHIN, TCP/IPCLEARLY EXPLAINED (1997) and DAVID GOURLEY AND BRIAN TOTTY, HTTP, THEDEFINITIVE GUIDE (2002), the contents of which are hereby incorporatedby reference.

The various system components may be independently, separately orcollectively suitably coupled to the network via data links whichincludes, for example, a connection to an Internet Service Provider(ISP) over the local loop as is typically used in connection withstandard modem communication, cable modem, Dish networks, ISDN, DigitalSubscriber Line (DSL), or various wireless communication methods, see,e.g., GILBERT HELD, UNDERSTANDING DATA COMMUNICATIONS (1996), which ishereby incorporated by reference. It is noted that the network may beimplemented as other types of networks, such as an interactivetelevision (ITV) network. Moreover, the system contemplates the use,sale or distribution of any goods, services or information over anynetwork having similar functionality described herein.

“Cloud” or “Cloud computing” includes a model for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g., networks, servers, storage, applications, and services)that can be rapidly provisioned and released with minimal managementeffort or service provider interaction. Cloud computing may includelocation-independent computing, whereby shared servers provideresources, software, and data to computers and other devices on demand.For more information regarding cloud computing, see the NIST's (NationalInstitute of Standards and Technology) definition of cloud computing athttp://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc (lastvisited Feb. 4, 2011), which is hereby incorporated by reference in itsentirety.

As used herein, “transmit” may include sending electronic data from onesystem component to another over a network connection. Additionally, asused herein, “data” may include encompassing information such ascommands, queries, files, data for storage, and the like in digital orany other form.

As used herein, “issue a debit”, “debit” or “debiting” refers to eithercausing the debiting of a stored value or prepaid card-type financialaccount, or causing the charging of a credit or charge card-typefinancial account, as applicable.

Phrases and terms similar to an “item” may include any good, service,information, experience, data, content, access, rental, lease,contribution, account, credit, debit, benefit, right, reward, points,coupons, credits, monetary equivalent, anything of value, something ofminimal or no value, monetary value, non-monetary value and/or the like.

The system contemplates uses in association with web services, utilitycomputing, pervasive and individualized computing, security and identitysolutions, autonomic computing, cloud computing, commodity computing,mobility and wireless solutions, open source, biometrics, grid computingand/or mesh computing.

Any databases discussed herein may include relational, hierarchical,graphical, or object-oriented structure and/or any other databaseconfigurations. Common database products that may be used to implementthe databases include DB2 by IBM (Armonk, N.Y.), various databaseproducts available from Oracle Corporation (Redwood Shores, Calif.),Microsoft Access or Microsoft SQL Server by Microsoft Corporation(Redmond, Wash.), MySQL by MySQL AB (Uppsala, Sweden), or any othersuitable database product. Moreover, the databases may be organized inany suitable manner, for example, as data tables or lookup tables. Eachrecord may be a single file, a series of files, a linked series of datafields or any other data structure. Association of certain data may beaccomplished through any desired data association technique such asthose known or practiced in the art. For example, the association may beaccomplished either manually or automatically. Automatic associationtechniques may include, for example, a database search, a databasemerge, GREP, AGREP, SQL, using a key field in the tables to speedsearches, sequential searches through all the tables and files, sortingrecords in the file according to a known order to simplify lookup,and/or the like. The association step may be accomplished by a databasemerge function, for example, using a “key field” in pre-selecteddatabases or data sectors. Various database tuning steps arecontemplated to optimize database performance. For example, frequentlyused files such as indexes may be placed on separate file systems toreduce In/Out (“I/O”) bottlenecks.

More particularly, a “key field” partitions the database according tothe high-level class of objects defined by the key field. For example,certain types of data may be designated as a key field in a plurality ofrelated data tables and the data tables may then be linked on the basisof the type of data in the key field. The data corresponding to the keyfield in each of the linked data tables is preferably the same or of thesame type. However, data tables having similar, though not identical,data in the key fields may also be linked by using AGREP, for example.In accordance with one embodiment, any suitable data storage techniquemay be utilized to store data without a standard format Data sets may bestored using any suitable technique, including, for example, storingindividual files using an ISO/IEC 7816-4 file structure; implementing adomain whereby a dedicated file is selected that exposes one or moreelementary files containing one or more data sets; using data setsstored in individual files using a hierarchical filing system; data setsstored as records in a single file (including compression, SQLaccessible, hashed via one or more keys, numeric, alphabetical by firsttuple, etc.); Binary Large Object (BLOB); stored as ungrouped dataelements encoded using ISO/IEC 7816-6 data elements; stored as ungroupeddata elements encoded using ISO/IEC Abstract Syntax Notation (ASN.1) asin ISO/IEC 8824 and 8825; and/or other proprietary techniques that mayinclude fractal compression methods, image compression methods, etc.

In one exemplary embodiment, the ability to store a wide variety ofinformation in different formats is facilitated by storing theinformation as a BLOB. Thus, any binary information can be stored in astorage space associated with a data set. As discussed above, the binaryinformation may be stored on the financial transaction instrument orexternal to but affiliated with the financial transaction instrument.The BLOB method may store data sets as ungrouped data elements formattedas a block of binary via a fixed memory offset using either fixedstorage allocation, circular queue techniques, or best practices withrespect to memory management (e.g., paged memory, least recently used,etc.). By using BLOB methods, the ability to store various data setsthat have different formats facilitates the storage of data associatedwith the financial transaction instrument by multiple and unrelatedowners of the data sets. For example, a first data set which may bestored may be provided by a first party, a second data set which may bestored may be provided by an unrelated second party, and yet a thirddata set which may be stored, may be provided by an third partyunrelated to the first and second party. Each of these three exemplarydata sets may contain different information that is stored usingdifferent data storage formats and/or techniques. Further, each data setmay contain subsets of data that also may be distinct from othersubsets.

As stated above, in various embodiments, the data can be stored withoutregard to a common format. However, in one exemplary embodiment, thedata set (e.g., BLOB) may be annotated in a standard manner whenprovided for manipulating the data onto the financial transactioninstrument. The annotation may comprise a short header, trailer, orother appropriate indicator related to each data set that is configuredto convey information useful in managing the various data sets. Forexample, the annotation may be called a “condition header”, “header”,“trailer”, or “status”, herein, and may comprise an indication of thestatus of the data set or may include an identifier correlated to aspecific issuer or owner of the data. In one example, the first threebytes of each data set BLOB may be configured or configurable toindicate the status of that particular data set; e.g., LOADED,INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED. Subsequent bytes ofdata may be used to indicate for example, the identity of the issuer,user, transaction/membership account identifier or the like. Each ofthese condition annotations are further discussed herein.

The data set annotation may also be used for other types of statusinformation as well as various other purposes. For example, the data setannotation may include security information establishing access levels.The access levels may, for example, be configured to permit only certainindividuals, levels of employees, companies, or other entities to accessdata sets, or to permit access to specific data sets based on thetransaction, merchant, issuer, user or the like. Furthermore, thesecurity information may restrict/permit only certain actions such asaccessing, modifying, and/or deleting data sets. In one example, thedata set annotation indicates that only the data set owner or the userare permitted to delete a data set, various identified users may bepermitted to access the data set for reading, and others are altogetherexcluded from accessing the data set. However, other access restrictionparameters may also be used allowing various entities to access a dataset with various permission levels as appropriate.

The data, including the header or trailer may be received by a standalone interaction device configured to add, delete, modify, or augmentthe data in accordance with the header or trailer. As such, in oneembodiment, the header or trailer is not stored on the transactiondevice along with the associated issuer-owned data but instead theappropriate action may be taken by providing to the transactioninstrument user at the stand alone device, the appropriate option forthe action to be taken. The system may contemplate a data storagearrangement wherein the header or trailer, or header or trailer history,of the data is stored on the transaction instrument in relation to theappropriate data.

One skilled in the art will also appreciate that, for security reasons,any databases, systems, devices, servers or other components of thesystem may consist of any combination thereof at a single location or atmultiple locations, wherein each database or system includes any ofvarious suitable security features, such as firewalls, access codes,encryption, decryption, compression, decompression, and/or the like.

Encryption may be performed by way of any of the techniques nowavailable in the art or which may become available—e.g., Twofish, RSA,El Gamal, Schorr signature, DSA, PGP, PKI, and symmetric and asymmetriccryptosystems.

The computing unit of the web client may be further equipped with anInternet browser connected to the Internet or an intranet using standarddial-up, cable, DSL or any other Internet protocol known in the art.Transactions originating at a web client may pass through a firewall inorder to prevent unauthorized access from users of other networks.Further, additional firewalls may be deployed between the varyingcomponents of CMS to further enhance security.

Firewall may include any hardware and/or software suitably configured toprotect CMS components and/or enterprise computing resources from usersof other networks. Further, a firewall may be configured to limit orrestrict access to various systems and components behind the firewallfor web clients connecting through a web server. Firewall may reside invarying configurations including Stateful Inspection, Proxy based,access control lists, and Packet Filtering among others. Firewall may beintegrated within an web server or any other CMS components or mayfurther reside as a separate entity. A firewall may implement networkaddress translation (“NAT”) and/or network address port translation(“NAPT”). A firewall may accommodate various tunneling protocols tofacilitate secure communications, such as those used in virtual privatenetworking. A firewall may implement a demilitarized zone (“DMZ”) tofacilitate communications with a public network such as the Internet. Afirewall may be integrated as software within an Internet server, anyother application server components or may reside within anothercomputing device or may take the form of a standalone hardwarecomponent.

The computers discussed herein may provide a suitable website or otherInternet-based graphical user interface which is accessible by users. Inone embodiment, the Microsoft Internet Information Server (IIS),Microsoft Transaction Server (MTS), and Microsoft SQL Server, are usedin conjunction with the Microsoft operating system, Microsoft NT webserver software, a Microsoft SQL Server database system, and a MicrosoftCommerce Server. Additionally, components such as Access or MicrosoftSQL Server, Oracle, Sybase, Informix MySQL, Interbase, etc., may be usedto provide an Active Data Object (ADO) compliant database managementsystem. In one embodiment, the Apache web server is used in conjunctionwith a Linux operating system, a MySQL database, and the Perl, PHP,and/or Python programming languages.

Any of the communications, inputs, storage, databases or displaysdiscussed herein may be facilitated through a website having web pages.The term “web page” as it is used herein is not meant to limit the typeof documents and applications that might be used to interact with theuser. For example, a typical website might include, in addition tostandard HTML documents, various forms, Java applets, JavaScript, activeserver pages (ASP), common gateway interface scripts (CGI), extensiblemarkup language (XML), dynamic HTML, cascading style sheets (CSS), AJAX(Asynchronous Javascript And XML), helper applications, plug-ins, andthe like. A server may include a web service that receives a requestfrom a web server, the request including a URL(http://yahoo.com/stockquotes/ge) and an IP address (123.56.789.234).The web server retrieves the appropriate web pages and sends the data orapplications for the web pages to the IP address. Web services areapplications that are capable of interacting with other applicationsover a communications means, such as the internet. Web services aretypically based on standards or protocols such as XML, SOAP, AJAX, WSDLand UDDI. Web services methods are well known in the art, and arecovered in many standard texts. See, e.g., ALEX NGHIEM, IT WEB SERVICES:A ROADMAP FOR THE ENTERPRISE (2003), hereby incorporated by reference.

Middleware may include any hardware and/or software suitably configuredto facilitate communications and/or process transactions betweendisparate computing systems. Middleware components are commerciallyavailable and known in the art. Middleware may be implemented throughcommercially available hardware and/or software, through custom hardwareand/or software components, or through a combination thereof. Middlewaremay reside in a variety of configurations and may exist as a standalonesystem or may be a software component residing on the Internet server.Middleware may be configured to process transactions between the variouscomponents of an application server and any number of internal orexternal systems for any of the purposes disclosed herein. WebSphere MQ™(formerly MQSeries) by IBM, Inc. (Armonk, N.Y.) is an example of acommercially available middleware product. An Enterprise Service Bus(“ESB”) application is another example of middleware.

Practitioners will also appreciate that there are a number of methodsfor displaying data within a browser-based document. Data may berepresented as standard text or within a fixed list, scrollable list,drop-down list, editable text field, fixed text field, pop-up window,and the like. Likewise, there are a number of methods available formodifying data in a web page such as, for example, free text entry usinga keyboard, selection of menu items, check boxes, option boxes, and thelike.

The system and method may be described herein in terms of functionalblock components, screen shots, optional selections and variousprocessing steps. It should be appreciated that such functional blocksmay be realized by any number of hardware and/or software componentsconfigured to perform the specified functions. For example, the systemmay employ various integrated circuit components, e.g., memory elements,processing elements, logic elements, look-up tables, and the like, whichmay carry out a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of the system may be implemented with any programming orscripting language such as C, C++, C#, Java, JavaScript, VBScript,Macromedia Cold Fusion, COBOL, Microsoft Active Server Pages, assembly,PERL, PHP, awk, Python, Visual Basic, SQL Stored Procedures, PL/SQL, anyUNIX shell script, and extensible markup language (XML) with the variousalgorithms being implemented with any combination of data structures,objects, processes, routines or other programming elements. Further, itshould be noted that the system may employ any number of conventionaltechniques for data transmission, signaling, data processing, networkcontrol, and the like. Still further, the system could be used to detector prevent security issues with a client-side scripting language, suchas JavaScript, VBScript or the like. For a basic introduction ofcryptography and network security, see any of the following references:(1) “Applied Cryptography: Protocols, Algorithms, And Source Code In C,”by Bruce Schneier, published by John Wiley & Sons (second edition,1995); (2) “Java Cryptography” by Jonathan Knudson, published byO'Reilly & Associates (1998); (3) “Cryptography & Network Security:Principles & Practice” by William Stallings, published by Prentice Hall;all of which are hereby incorporated by reference.

As used herein, the term “end user”, “consumer”, “customer”,“cardmember”, “business” or “merchant” may be used interchangeably witheach other, and each shall mean any person, entity, machine, hardware,software or business. A bank may be part of the system, but the bank mayrepresent other types of card issuing institutions, such as credit cardcompanies, card sponsoring companies, or third party issuers undercontract with financial institutions. It is further noted that otherparticipants may be involved in some phases of the transaction, such asan intermediary settlement institution, but these participants are notshown.

Each participant is equipped with a computing device in order tointeract with the system and facilitate online commerce transactions.The customer has a computing unit in the form of a personal computer,although other types of computing units may be used including laptops,notebooks, hand held computers, set-top boxes, cellular telephones,touch-tone telephones and the like. The merchant has a computing unitimplemented in the form of a computer-server, although otherimplementations are contemplated by the system. The bank has a computingcenter shown as a main frame computer. However, the bank computingcenter may be implemented in other forms, such as a mini-computer, a PCserver, a network of computers located in the same of differentgeographic locations, or the like. Moreover, the system contemplates theuse, sale or distribution of any goods, services or information over anynetwork having similar functionality described herein

The merchant computer and the bank computer may be interconnected via asecond network, referred to as a payment network. The payment networkwhich may be part of certain transactions represents existingproprietary networks that presently accommodate transactions for creditcards, debit cards, and other types of financial/banking cards. Thepayment network is a closed network that is assumed to be secure fromeavesdroppers. Exemplary transaction networks may include the AmericanExpress®, VisaNet® and the Veriphone® networks.

As will be appreciated by one of ordinary skill in the art, the systemmay be embodied as a customization of an existing system, an add-onproduct, upgraded software, a stand alone system, a distributed system,a method, a data processing system, a device for data processing, and/ora computer program product. Accordingly, the system may take the form ofan entirely software embodiment, an entirely hardware embodiment, or anembodiment combining aspects of both software and hardware. Furthermore,the system may take the form of a computer program product on acomputer-readable storage medium having computer-readable program codemeans embodied in the storage medium. Any suitable computer-readablestorage medium may be utilized, including hard disks, CD-ROM, opticalstorage devices, magnetic storage devices, and/or the like.

The system and method is described herein with reference to screenshots, block diagrams and flowchart illustrations of methods, apparatus(e.g., systems), and computer program products according to variousembodiments. It will be understood that each functional block of theblock diagrams and the flowchart illustrations, and combinations offunctional blocks in the block diagrams and flowchart illustrations,respectively, can be implemented by computer program instructions.

These computer program instructions may be loaded onto a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructionsthat execute on the computer or other programmable data processingapparatus create means for implementing the functions specified in theflowchart block or blocks. These computer program instructions may alsobe stored in a computer-readable memory that can direct a computer orother programmable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function specified in the flowchart block or blocks.The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified in theflowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions. Further, illustrations ofthe process flows and the descriptions thereof may make reference touser windows, webpages, websites, web forms, prompts, etc. Practitionerswill appreciate that the illustrated steps described herein may comprisein any number of configurations including the use of windows, webpages,web forms, popup windows, prompts and the like. It should be furtherappreciated that the multiple steps as illustrated and described may becombined into single webpages and/or windows but have been expanded forthe sake of simplicity. In other cases, steps illustrated and describedas single process steps may be separated into multiple webpages and/orwindows but have been combined for simplicity.

Phrases and terms similar to “account”, “account number”, “account code”or “consumer account” as used herein, may include any device, code(e.g., one or more of an authorization/access code, personalidentification number (“PIN”), Internet code, other identification code,and/or the like), number, letter, symbol, digital certificate, smartchip, digital signal, analog signal, biometric or otheridentifier/indicia suitably configured to allow the consumer to access,interact with or communicate with the system. The account number mayoptionally be located on or associated with a rewards account, chargeaccount, credit account, debit account, prepaid account, telephone card,embossed card, smart card, magnetic stripe card, bar code card,transponder, radio frequency card or an associated account.

The system may include or interface with any of the foregoing accountsor devices, a transponder and reader in RF communication with thetransponder (which may include a fob), or communications between aninitiator and a target enabled by near field communications (NFC).Typical devices may include, for example, a key ring, tag, card, cellphone, wristwatch or any such form capable of being presented forinterrogation. Moreover, the system, computing unit or device discussedherein may include a “pervasive computing device,” which may include atraditionally non-computerized device that is embedded with a computingunit. Examples may include watches, Internet enabled kitchen appliances,restaurant tables embedded with RF readers, wallets or purses withimbedded transponders, etc. Furthermore, a device or financialtransaction instrument may have electronic and communicationsfunctionality enabled, for example, by: a network of electroniccircuitry that is printed or otherwise incorporated onto or within thetransaction instrument (and typically referred to as a “smart card”); afob having a transponder and an RFID reader; and/or near fieldcommunication (NFC) technologies. For more information regarding NFC,refer to the following specifications all of which are incorporated byreference herein: ISO/IEC 18092/ECMA-340, Near Field CommunicationInterface and Protocol-1 (NFCIP-1); ISO/IEC 21481/ECMA-352, Near FieldCommunication Interface and Protocol-2 (NFCIP-2); and EMV 4.2 availableat http://www.emvco.com/default.aspx.

The account number may be distributed and stored in any form of plastic,electronic, magnetic, radio frequency, wireless, audio and/or opticaldevice capable of transmitting or downloading data from itself to asecond device. A consumer account number may be, for example, asixteen-digit account number, although each credit provider has its ownnumbering system, such as the fifteen-digit numbering system used byAmerican Express. Each company's account numbers comply with thatcompany's standardized format such that the company using afifteen-digit format will generally use three-spaced sets of numbers, asrepresented by the number “0000 000000 00000”. The first five to sevendigits are reserved for processing purposes and identify the issuingbank, account type, etc. In this example, the last (fifteenth) digit isused as a sum check for the fifteen digit number. The intermediaryeight-to-eleven digits are used to uniquely identify the consumer. Amerchant account number may be, for example, any number or alpha-numericcharacters that identify a particular merchant for purposes of accountacceptance, account reconciliation, reporting, or the like.

Phrases and terms similar to “transaction account” may include anyaccount that may be used to facilitate a financial transaction.

Phrases and terms similar to “financial institution” or “transactionaccount issuer” may include any entity that offers transaction accountservices. Although often referred to as a “financial institution,” thefinancial institution may represent any type of bank, lender or othertype of account issuing institution, such as credit card companies, cardsponsoring companies, or third party issuers under contract withfinancial institutions. It is further noted that other participants maybe involved in some phases of the transaction, such as an intermediarysettlement institution.

The terms “payment vehicle,” “financial transaction instrument,”“transaction instrument” and/or the plural form of these terms may beused interchangeably throughout to refer to a financial instrument.

As used herein, the meaning of the term “non-transitorycomputer-readable medium” should be construed to exclude only thosetypes of transitory computer-readable media which were found in In reNuijten, 500 F.3d 1346 (Fed. Cir. 2007) to fall outside the scope ofpatentable subject matter under 35 U.S.C. §101, so long as and to theextent In re Nuijten remains binding authority in the U.S. federalcourts and is not overruled by a future case or statute. Stated anotherway, the term “computer-readable medium” should be construed in a mannerthat is as broad as legally permissible

Benefits, other advantages, and solutions to problems have beendescribed herein with regard to specific embodiments. However, thebenefits, advantages, solutions to problems, and any elements that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as critical, required, or essentialfeatures or elements of the disclosure. The scope of the disclosure isaccordingly to be limited by nothing other than the appended claims, inwhich reference to an element in the singular is not intended to mean“one and only one” unless explicitly so stated, but rather “one ormore.” Moreover, where a phrase similar to ‘at least one of A, B, and C’or ‘at least one of A, B, or C’ is used in the claims or specification,it is intended that the phrase be interpreted to mean that A alone maybe present in an embodiment, B alone may be present in an embodiment, Calone may be present in an embodiment, or that any combination of theelements A, B and C may be present in a single embodiment; for example,A and B, A and C, B and C, or A and B and C. Although the disclosureincludes a method, it is contemplated that it may be embodied ascomputer program instructions on a tangible computer-readable carrier,such as a magnetic or optical memory or a magnetic or optical disk. Allstructural, chemical, and functional equivalents to the elements of theabove-described exemplary embodiments that are known to those ofordinary skill in the art are expressly incorporated herein by referenceand are intended to be encompassed by the present claims. Moreover, itis not necessary for a device or method to address each and everyproblem sought to be solved by the present disclosure, for it to beencompassed by the present claims. Furthermore, no element, component,or method step in the present disclosure is intended to be dedicated tothe public regardless of whether the element, component, or method stepis explicitly recited in the claims. No claim element herein is to beconstrued under the provisions of 35 U.S.C. 112, sixth paragraph, unlessthe element is expressly recited using the phrase “means for.” As usedherein, the terms “comprises”, “comprising”, or any other variationthereof, are intended to cover a non-exclusive inclusion, such that aprocess, method, article, or apparatus that comprises a list of elementsdoes not include only those elements but may include other elements notexpressly listed or inherent to such process, method, article, orapparatus.

What is claimed is:
 1. A method comprising: receiving, at acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, credit reporting data relating toa tradeline, wherein the credit reporting data is encapsulated in aMetro 2 format container; parsing, by the computer-based system, thecredit reporting data to yield primary debtor data and secondary debtordata wherein the parsing is performed on at least one of a J1 segment, aJ2 segment, and a Base segment of the Metro 2 format container; linking,by the computer-based system, the tradeline with the primary debtor dataand the secondary debtor data, wherein the linking comprises updating afirst record relating to the primary debtor and a second record relatingto the secondary debtor.
 2. The method of claim 1, wherein the firstrecord and the second record reside in a data store containing creditbureau data.
 3. The method of claim 1, further comprising querying thedata store for at least one of the number of individual tradelines of atleast one of the primary debtor and the secondary debtor.
 4. The methodof claim 3, further comprising querying the data store for tradelinesassociated with the primary debtor and the secondary debtor to yield ahousehold tradeline data set.
 5. The method of claim 4, furthercomprising identifying at least one of the number of joint trades in thehousehold tradeline data set.
 6. A method comprising: identifying, by acomputer-based system for credit data analysis comprising a processorand a tangible, non-transitory memory, tradeline data associated with aprimary debtor in a data store containing credit bureau data, whereinthe tradeline data is associated with a tradeline; combining, by thecomputer-based system, a subset of the tradeline data using afingerprinting function to yield a tradeline fingerprint; querying, bythe computer-based system, the data store for the tradeline fingerprintto retrieve a secondary debtor associated with the tradelinefingerprint.
 7. The method of claim 6, further comprising receivingcredit reporting data relating to a tradeline, wherein the creditreporting data is encapsulated in a Metro 2 format container.
 8. Themethod of claim 7, further comprising storing a record associating thesecondary debtor to the tradeline data.
 9. The method of claim 8,further comprising parsing the credit reporting data to obtain theprimary debtor and the secondary debtor.
 10. The method of claim 9,further comprising confirming the association of the primary debtor andthe secondary debtor using the credit reporting data.
 11. The method ofclaim 8, wherein the parsing the credit reporting data comprises parsingat least one of the J1 segment and the J2 segment.
 12. The method ofclaim 8, wherein the parsing the credit reporting data comprises parsinga Base segment.
 13. A system for credit data analysis, the systemcomprising: a non-transitory memory communicating with a processor forcredit data analysis, the non-transitory memory having instructionsstored thereon that, in response to execution by the processor, causethe processor to perform operations comprising: receiving, at theprocessor, credit reporting data relating to a tradeline, wherein thecredit reporting data is encapsulated in a Metro 2 format container;parsing, by the processor, the credit reporting data to yield primarydebtor data and secondary debtor data, wherein the parsing is performedon at least one of a J1 segment, a J2 segment, and a Base segment of theMetro 2 format container; linking, by the processor, the tradeline withthe primary debtor data and the secondary debtor data, wherein thelinking comprises updating a first record relating to the primary debtorand a second record relating to the secondary debtor.
 14. The system ofclaim 13, wherein the first record and the second record reside in adata store containing credit bureau data.
 15. The system of claim 13,further comprising querying the data store for at least one of thenumber of individual tradelines of at least one of the primary debtorand the secondary debtor.